What Production-Ready Actually Means: A Definition
Production-ready isn't a feeling. It's six properties you can check: security, data safety, observability, recoverability, performance and maintainability.
“Production-ready” means an app can serve real users and their data without its author constantly watching over it: it doesn’t hand out other people’s data, doesn’t lose what was saved, reports its own failures and survives them. It’s not about the number of features. It’s about what happens when something goes wrong.
The trouble is that the phrase usually describes a feeling: “seems to work”. A vibe-coded MVP almost always works on the demo, for its author, with tidy data. Below are six properties that let you check readiness instead of sensing it.
Why “it works” isn’t the same as production-ready
A demo tests one scenario: a person does what was intended. Production tests all the others: empty fields, double clicks, slow connections, a hundred users at once, one user with bad intentions, a third-party service going down at 3 a.m.
Being production-ready is the answer to “what happens if…”, not “what happens when everything goes right”.
1. Security
The app gives each person only their own data and doesn’t trust what arrives from the browser.
Checkable signs:
- data access is enforced on the server, not just by a hidden button in the UI;
- there are no secret keys in client-side code;
- login and password reset are protected against brute force;
- dependencies have no known vulnerabilities.
2. Data safety
Data entrusted to the app doesn’t disappear or get corrupted.
- automatic backups exist, and someone has actually restored from one at least once;
- database schema changes go through migrations, not manual edits;
- a resubmitted form or a repeated webhook doesn’t create duplicates.
3. Observability
You find out about a problem before your users do, and you can figure out what happened.
- errors are collected in one place and trigger a notification;
- logs contain enough to trace a specific request, but no passwords or tokens;
- there’s a simple “is the site up” check that doesn’t depend on your own browser.
4. Recoverability
When something does break, it can be fixed quickly and without heroics.
- a bad release can be rolled back in minutes;
- the app can be deployed from scratch using written instructions or a script, not memory;
- there’s a clear plan for an outage and it’s clear who carries it out.
5. Performance
The app stays fast under real load, not just with an empty database.
- the main pages load quickly on an average phone over mobile data;
- frequent database queries use indexes;
- expensive operations such as AI calls, sending email and processing files are rate-limited and don’t block the interface.
6. Maintainability
The code can be changed by someone other than its author, including you in three months, or an AI assistant with no context.
- the project runs locally by following the README;
- there are tests for at least the parts that make money or store data: login, payments, saving;
- there aren’t five copies of the same logic in different files;
- settings live in environment variables, and environments are separated.
How to use this definition
You don’t need to perfect every property before launch. You need to know where you stand. Go through the six and answer honestly for each: “yes”, “partly” or “no”.
Then a simple priority rule. Anything about security and data safety gets fixed before the first real users, because those mistakes are irreversible: leaked data doesn’t come back. Observability and recovery come before money starts depending on the app. Performance and maintainability can grow as you go, as long as they don’t hold growth back.
It helps to write the result into the repository as a short list in the README. A month later you’ll see what actually moved, not just a feeling that things “got better”.
In short
- Production-ready means the app can handle real users without its author constantly watching it.
- Readiness is checked against six properties: security, data safety, observability, recoverability, performance, maintainability.
- Each property has concrete signs you can check in an evening.
- Security and data before launch, observability and rollback before revenue, the rest as you grow.
- A written assessment beats the feeling that “it seems to work”.
If you’d like that assessment from the outside, SUBXCAT goes through these six points on a live project and fixes what falls short.