What Production Ready Actually Means: The 7 Gates

A production-ready product is one that keeps its promises to a real customer when the person who built it is asleep. Not that the feature works. That it keeps working, that someone finds out first when it does not, and that the next change does not break the last one.

Why the question is suddenly everywhere

The demo got easy. Building something that looks real, responds well, and can impress an investor on a screen share is now within reach for a founder using Lovable, Bolt, Replit, Cursor, Claude, or a contractor. What has not gotten easy is the part that matters after the call ends: data integrity, change management, operational visibility, and the ability to keep shipping without turning every release into a fire drill.

That gap is why the phrase production ready is suddenly everywhere and still defined nowhere. Search results are full of queries like make my vibe coded app production ready, make lovable app production ready, is vibe coding production ready, and mvp not production ready. The person asking is usually not an engineer. They are the person who paid for the software, is being told it is not ready, and needs to know whether that means “one more week” or “start over.”

If you ask the wrong question, you get the wrong answer. “Is this production ready?” is too vague to be useful if the only person who can answer is the same agent or builder that wrote the code. That is not a check. It is a self-assessment. The better question is: what evidence would prove this product can safely serve customers today, and what evidence would prove it can absorb the next eighteen months of change?

Production ready is two questions, not one

Ready to serve

This is the narrow version. Can real customers use it today without being hurt by obvious failures? Does it authenticate correctly, handle errors safely, protect data, alert someone when things go wrong, and recover in a reasonable time?

Ready to build on

This is the expensive version, and it is where most demos fail. Can the system change without collapsing under its own history? Is the data model sane? Are tests enforced? Are deployments routine? Is the codebase documented and owned? Can a new engineer take over without asking the founder to explain the whole thing from memory?

Many products can pass the first question and fail the second. That is why they launch and then stall. The market sees a working app. The team sees a growing pile of hidden fragility. The business pays for the second failure later, in slower releases, larger defects, and expensive rework.

The Seven Gates

Here is the practical definition. A product is production ready when it clears seven gates. Each gate has a plain-language claim, a piece of evidence a non-technical owner can ask to see, and a business consequence if you skip it.

Gate 1. The data model holds

Claim: The shape of the data matches the shape of the business, and changing it later will not require a rewrite.

Ask to see: a one-page diagram of the core entities and relationships; a walkthrough of what happens when a customer changes plan, cancels, or gets refunded; how schema changes are applied to live data without downtime.

Why it matters: This is the most expensive thing to fix later because every feature grows on top of it. If the model is wrong, the product may still “work,” but every serious change becomes a negotiation with the past.

Gate 2. Nothing reaches customers without a second pair of eyes

Claim: Every change is reviewed by a senior engineer before it ships, including changes written by AI.

Ask to see: the last ten merged pull requests; who approved each one; whether any substantive review comments were left; whether the main branch is protected.

Why it matters: AI-generated code can look correct and still be wrong in exactly the ways that matter most. Review is the control that catches the mistake before the customer does.

Gate 3. The tests fail when the product is broken

Claim: Critical paths are covered by automated tests, the tests run on every change, and a failing test blocks the merge.

Ask to see: the coverage number and whether it is enforced; a deliberate break of a core flow to watch the pipeline go red; the list of customer journeys covered end to end.

Why it matters: Without enforced tests, every release becomes manual regression hunting. That works at first. Then it becomes the bottleneck that kills momentum.

Gate 4. Shipping is boring and reversible

Claim: Deploying is routine and any release can be rolled back quickly.

Ask to see: how many deploys happened last week; how long one deploy takes; a live deployment; the rollback procedure; the last time rollback was actually used.

Why it matters: If shipping is dramatic, teams batch changes. If they batch changes, every release gets riskier. The product stops improving because every change feels like a bet.

Gate 5. You find out before your customer tells you

Claim: Errors, latency, and business-critical failures are logged, alerted, and traceable to a specific request or customer flow.

Ask to see: the last three alerts that fired and what happened next; a dashboard for one real business flow such as signup or payment; whether a single failing transaction can be traced end to end.

Why it matters: If your customer is your monitoring system, you are already late.

Gate 6. The environment is described, not remembered

Claim: Infrastructure and configuration are defined as code, secrets are handled properly, and the environment can be rebuilt.

Ask to see: where the infrastructure definition lives in the repository; how a new engineer gets a working environment; where secrets are stored and who can read them.

Why it matters: If the product depends on one person’s laptop and memory, you do not own a system. You own a precarious habit.

Gate 7. The codebase is yours and someone else could take it over

Claim: You own the repository and the cloud accounts, the architecture is documented, and a competent team could pick it up without you.

Ask to see: whose organization owns the repository and cloud accounts; the README and architecture notes; what onboarding a new engineer would look like next Monday.

Why it matters: A product that only works with its original builder is not a product. It is a dependency.

What the list does not mean

Production ready does not mean feature complete. It does not mean the roadmap is done. It does not mean there are no bugs. It does not mean the product is scaled for a million users it does not yet have.

It also does not mean perfection. A broken-window policy is not a zero-defect fantasy. It means small decay does not get to accumulate unnoticed. You fix the cracks before they become the culture.

That distinction matters because founders often hear “not production ready” and assume “not good enough to launch.” Sometimes the truth is more specific: it is good enough to serve, but not yet good enough to keep building on safely. Those are different problems, with different costs.

What is a production ready MVP?

An MVP is production ready only if it can safely handle the first real users and survive the next round of change. The “minimum” in MVP should describe scope, not negligence. A production-ready MVP can be small, even rough around the edges, but it still has to clear the gates that prevent customer harm and future paralysis.

If someone tells you an MVP is “not production ready,” ask which gate failed. An MVP may reasonably skip enterprise-grade complexity, but it should not skip review, tests on critical flows, backups, observability, or ownership of the system. Those are not luxuries. They are the floor.

Is vibe coding production ready?

Sometimes the answer is yes for a narrow, low-risk internal tool. Often the answer is no for anything that stores customer data, handles money, or must keep changing after launch. The point is not who wrote the code. The point is whether the codebase is governed well enough to survive real use.

That is why “ask the agent if the codebase is production ready” is the wrong check. An agent can describe the code. It cannot vouch for the operating discipline around it. The real test is evidence: review, tests, deployment, monitoring, configuration, and ownership.

Regulated and complex domains raise the bar

In fintech, the gates expand to include ledger integrity, idempotency, reconciliation, and audit trail. In healthcare, they expand to include access controls, BAAs, audit logging, and privacy controls. In enterprise software, the security review will ask where secrets live, who can access production, how incidents are detected, and how data is isolated.

That does not change the definition of production ready. It raises the standard for each gate. The shape stays the same; the evidence gets stricter.

How to run this assessment on your own product this week

Do not ask for a philosophical discussion. Ask for a working session with the person who owns the codebase, the person who owns operations, and whoever is responsible for the product outcome. Then ask the seven questions in order.

• Show me the data model and explain the hardest upcoming schema change.
• Show me the last ten pull requests and who approved them.
• Show me the test coverage and break a critical flow on purpose.
• Show me a deploy and the rollback process.
• Show me the last three alerts and the dashboard behind them.
• Show me where the infrastructure lives and how secrets are managed.
• Show me who owns the repository and how a new engineer would start.

What does a confident answer sound like? Specifics. Screens. Names. Numbers. What does deflection sound like? “It should be fine.” “We usually know.” “That’s handled in another tool.” “I’d have to ask the agent.”

If you fail four or more gates, that usually does not mean rewrite. It means stop layering features on top of a weak foundation and fix the system in the order that reduces risk fastest. Most of the time the expensive work is not replacement. It is making the product governable.

Where a real standard is written down

Production readiness should not be a private opinion. It should be inspectable. The best engineering standards are public, concrete, and boring in exactly the right way. That is why we publish ours in the open-source flask-react-template and the Engineering Handbook: data model and architecture first, mandatory senior review on every change, enforced coverage, CI/CD, observability, infrastructure as code, broken-window discipline, and a codebase the customer owns.

That is also the standard you should hold any partner to. Not a promise. A written system. Because “production ready” is not a vibe, and it is not a label you buy at launch. It is the evidence that a real customer can depend on what you built, and that your team can keep building on it without fear.

That is what the term should mean. Anything less is a demo with a billing plan.