Production ready isn't a judgement about code quality. It's a short list of concrete properties: you can recover from a mistake, users can't reach each other's data, secrets aren't public, and you find out about failures before your customers do. Most prototypes fail two of those four.
If any of these is missing, the risk isn't inconvenience — it's the kind of incident you don't fully recover from.
This distinction accounts for more serious findings in AI-built apps than everything else combined, and it's worth stating plainly. Authentication establishes who someone is. Authorization establishes whether they're allowed to touch this particular record.
Generated code reliably implements the first and frequently omits the second, because the prompt asked for a login system rather than for an ownership check on every endpoint. The result is an app where changing a number in a URL returns somebody else's data.
It takes about ten minutes to test: log in as one user, take a record ID belonging to another, and request it directly.
These matter, but not every launch needs them on day one. What matters is that you've decided, rather than never considered them.
The difference between a team that gets away with a thin launch and one that doesn't is rarely the number of gaps. It's whether the gaps are written down with owners and dates, or discovered during an incident at the worst possible moment.
Deciding not to fix something yet is engineering. Not knowing about it isn't.
Yes, and it’s a good moment to ask. A pre-launch review covers architecture, security, performance, dependencies and maintainability, and comes back as a prioritized list rather than a wall of comments.
Yes, and it’s one of the most common reasons people get in touch. "It works locally" is almost always an environment, configuration or build problem rather than a code problem, and those are findable.
Yes, as an engineering review rather than a formal audit or certification. I look at authentication, authorization, exposed secrets, input handling, dependency risk and what your deployment leaves open. If you need a certified penetration test, I’ll tell you that instead of pretending otherwise.
The service
It works when you use it. Production means it has to work when a stranger uses it, at 3am, on a bad connection, while something upstream is down — and you have to find out when it doesn't.
Working is not production ready. Twelve checks: backups, authorization, secrets, error visibility, rate limits and rollback — and what each costs if skipped.
Read
10 min read
Nine differences between your machine and production, in the order they break: env vars, build output, ports, database, CORS, paths, time, memory and secrets.
Read
9 min read
Sometimes it needs an engineer.
Send the messy version. That’s usually the useful version.