With AI, it became easy to get to software that works in the demo. In one afternoon you can have screens, a database and a login. The question that matters comes later: will it hold up with real people using it?
“Production-ready” has become a vague phrase that everyone uses their own way. For me, it’s a short list of questions. In the team I lead, that list became a standard every repository follows, checked automatically. But it works for any product, of any size.
First the floor, then the ceiling
You can’t do everything on day one, and you don’t need to. I split the questions into three layers: the floor, which prevents disaster; the routine, which lets the team change the product without fear; and growth, which gets you ready for when it works.
The floor: what can’t be missing on day one
1. Is there a key or password in the code? It’s the most common mistake and the most expensive. An API key forgotten in the repository, a database password in a config file, a token in a screenshot. If it leaks, someone uses your account before you notice. Secrets stay out of the code, and the repository blocks anyone who tries to push one.
2. Who can read the data? A database open to anyone who knows the address, permissions nobody has reviewed, an admin panel with no login. And if the product stores people’s data, the next question is: what is stored, who can access it and why. In Brazil, the data protection law (LGPD, similar to Europe’s GDPR) asks for exactly those answers.
3. Is there a single way to deploy? If each person ships in their own way, nobody knows what’s running. There has to be one way, automated, from a protected branch, and it has to let you roll back to the previous version in minutes.
The routine: changing without fear
4. Can a change break what already worked without anyone noticing? I don’t chase a test coverage percentage. A high number can be reached with useless tests, and anyone in the field knows it. What I check is whether the critical paths are tested (sign-up, login, payment, whatever makes money or causes trouble) and whether the tests run on their own with every change.
5. Does anyone find out about an error before the customer complains? If the first sign that something broke is an angry message to support, the product is running in the dark. Errors need to trigger alerts, and alerts need to reach someone who looks at them.
Growth: when it works
6. What happens with ten times more users, and how much does it cost? A lot of things work with a hundred users and fall over with a thousand. Sometimes they don’t fall over, but the server bill grows faster than revenue. Better to know beforehand.
7. Can a new person work on it? I measure it with a simple question: can a developer who has never seen the project run it on their own machine in under an hour? If not, the product depends on whoever wrote it, and that’s a risk, not a detail.
Where AI comes in
AI helps a lot with this list. It reviews code looking for forgotten secrets, suggests tests, does the first triage of security alerts. In my team, much of this already runs with it.
What it doesn’t do is decide what’s critical. Knowing that payment matters more than the settings screen, or that a specific piece of data can’t leak under any circumstances, depends on someone who knows the business and the user. It’s the kind of decision I like to make looking at the whole product.
Ready isn’t perfect
Production-ready doesn’t mean bug-free. It means knowing what can go wrong, finding out when it does and being able to fix it fast.
If you have a product live, ask these seven questions today. Wherever the answer is “I don’t know”, that’s where I’d start.