What 'Production Ready' Actually Means
Everyone in software says it and almost nobody defines it, which is how projects get signed off in a state no customer should ever meet. Here's the plain-English checklist, in the order that matters, plus which items are genuine launch blockers and which can wait a fortnight.
Jake Moreland
Senior Engineer, Initial Studios
"It's production ready" is one of those phrases that sounds like a fact and functions like a mood.
I've heard it used about software that had never handled a real payment. I've also heard it withheld from software that had been quietly running a business for two years. It's not a standard anyone certifies. It's a claim, and when a builder and an owner use it, they're usually describing two different things: the builder means the code is finished, and the owner hears that the thing is safe to sell.
So here's the definition I'd defend, and then the checklist underneath it.
Production ready means it keeps working when nobody is watching, for people who don't know how it was built, and you'd find out before your customers if it stopped.
That's it. Notice what isn't in there. Not finished. Not perfect. Not impressive.
The nine-point checklist
Run these against what you've got. Be honest, because the point of the list is to find the noes.
1. It survives real data. Not Test Test of 123 Test Street. Names with apostrophes, business names with an ampersand, PO boxes, four-digit postcodes typed with a space, phone numbers pasted with the country code, an address in Woolloomooloo that runs off the end of the card, a photo straight off an iPhone that's enormous. If you haven't fed it a hundred realistic records, you don't know yet. This one is cheap to test and it fails more often than anything else on the list.
2. It keeps people's data apart. The moment there are two customers, the software has to know whose is whose, every single time, including on the screens you built early and forgot about. This is the item that turns a bad day into a serious one, because a customer seeing another customer's details is not a bug you can quietly patch and move on from.
3. It doesn't lose things. Backups exist, they run on their own, and, the bit everybody skips, you have actually restored one. A backup you've never restored is a belief, not a backup. Do the restore once, write down how long it took, and you'll sleep better than most business owners in the country.
4. It tells you when it breaks. Something is watching, and it wakes a human up rather than filing a report nobody reads. The worst version of a broken checkout isn't the outage, it's the seventeen days before anyone noticed. If your monitoring is "a customer emails us", you're outsourcing your alerting to the people you least want doing it.
5. It handles no as well as yes. The card declines. The upload times out. The email service has a bad morning. Someone loses reception mid-form. Every one of those needs to end with the person knowing what happened and what to do next, rather than a white screen or, worse, a cheerful success message covering a failure.
6. You can change it without holding your breath. There's somewhere to try changes that isn't the live site, and there's a way back if a change goes badly. This is the difference between a business that improves its software weekly and one that's too frightened to touch it, which is a fear we've written about before in the Friday deploy.
7. Someone other than the person who built it can run it. The code is in a repository you can access, it starts up on a new machine without a phone call, and the handful of things worth knowing are written down somewhere that isn't a person's memory. One head and one laptop is a risk no matter how good the head is.
8. It behaves on a phone, on mobile data, out of town. Most of your customers will meet it on a phone, some of them on patchy regional coverage. Big images, heavy pages and forms that lose their contents on a dropout are the difference between an enquiry and a bounce. Test it on your own phone with wifi off, standing outside.
9. It's yours. Domain, hosting, code and data in accounts with your business name on them and your card behind them. If any part of the thing you're about to sell through depends on someone else's account staying open, fix that before launch, not after. The ownership audit takes about ten minutes.
What production ready is not
Worth saying plainly, because owners routinely delay launching over things that don't matter and launch over things that do.
It isn't feature complete. Half the features you've planned should not exist yet, and some of them never will once customers get their hands on it.
It isn't beautiful. Design matters, but a plain thing that works beats a gorgeous thing that drops orders, and being obvious beats being impressive, which is a hill this blog has already died on.
It isn't built to survive a million users. Building for traffic you don't have is one of the most reliable ways to spend money on nothing. What you want is something that fails politely and can be grown when growth actually shows up.
It isn't done. Launch day is the start of the work, not the end of it, which is its own article.
Which of these are actual launch blockers?
Not all nine carry the same weight on day one. If you're deciding what to fix this week, here's how I'd triage it.
Do not launch without these. Keeping people's data apart. Backups you've restored. Ownership of your accounts. Handling failed payments properly if money changes hands. Those four are the ones where the downside isn't inconvenience, it's a customer harmed, money lost, or a business you can't get back.
Fix in the first fortnight. Monitoring and alerts, real-data resilience, the mobile-on-bad-signal pass. You can go live with these rough if you're watching closely yourself, but the honeymoon where you check it hourly ends faster than you'd think.
Fix before you get busy. Somewhere to test changes safely, and getting the knowledge out of one person's head. Neither hurts on day one. Both hurt enormously the first time you need to move quickly, which is usually the week something is going well.
Print that order out and you've got a plan that fits on one page. Most of the panic in a first launch comes from treating all nine as equally urgent and therefore doing none of them.
Where most prototypes actually sit
Of the ones we look at, the pattern is remarkably consistent: strong on the first eighty per cent, missing five or six of these nine, and the owner already suspected which ones. People are usually right about their own gaps. What they're missing is permission to take them seriously and a sense of how long each takes to close, which is rarely as long as the dread suggests.
If you want that read on yours, send it over. We'll go through this exact list, tell you what's already fine, and be specific about what isn't.
Questions owners actually ask
- What does production ready mean in plain English?
- It means the software keeps working when nobody is watching, for people who didn't build it, and you'd find out before your customers if it stopped. In practice that comes down to a handful of things: real data doesn't break it, one customer can't see another's information, backups exist and have been restored, failures are handled gracefully, and someone is alerted when it goes down. It does not mean finished, feature complete or perfect.
- Do I need to worry about privacy law for a small Australian app?
- Whether the Privacy Act formally applies to your business depends on your size and what you handle, and health information brings its own obligations regardless of size, so it's worth getting proper advice rather than guessing. Commercially, though, the threshold question is a distraction: your customers will hold you to a much simpler standard, which is that their details don't end up somewhere they didn't expect. Store only what you need, keep it in an account your business controls, and know which country it sits in.
- How long does it take to make a prototype production ready?
- For a typical small-business app or MVP it's usually a matter of weeks rather than months, and it's driven by how many of the nine points are missing rather than by how big the app looks. Data separation, payment handling and backups are the items that most often add time, because they touch everything. The fastest way to get a real answer is to have someone go through the list against your actual build and give you the gaps in writing.