There is a phrase we have heard in a dozen variations over the years. “The MVP is ready. We are launching next week.” What the team usually means is that the product works when a friendly user clicks through the happy path on a laptop in the office. What the team does not usually mean is that the product can handle real customers, under real load, with real failure modes, without waking the engineering team at three in the morning.
The gap between those two definitions is the difference between a demo and a production system. It is also where most of the engineering work actually lives. Founders frequently underestimate this gap because the MVP looked so nearly done. Experienced engineering leaders know to measure the distance by the concrete milestones that separate the two.
This article lays out six of those milestones. Each one is a gate that a system has to pass through to be honestly called production-ready. Each one has a common shortcut. And each shortcut has a price that gets paid in the first serious outage.
Gate 1: Real authentication, not a placeholder
Most MVPs have some form of login. Very few have production-grade authentication. The difference is not whether a password can be entered. The difference is whether the system handles password reset flows, session management, rate-limited login attempts, account lockout on suspicious behavior, and secure credential storage with modern hashing.
What “done” looks like: password reset that cannot be abused to enumerate valid accounts; sessions with proper expiration and invalidation on logout and password change; rate limiting on authentication endpoints; credential storage using a modern hashing algorithm with appropriate work factor; multi-factor authentication available for administrative accounts at minimum.
The common shortcut: a basic email-and-password form, a direct database check, and a session cookie that expires whenever. It works in the demo. It also works for the first attacker who enumerates accounts via the password reset endpoint, finds one that exists, and starts brute-forcing the login form that has no rate limit.
The cost in the first outage: customer credential exposure, mandatory disclosure, lost trust, and in regulated industries, notification obligations that can cost more than the engineering work to do it correctly from the start.
Gate 2: Operational observability
A system in production needs to answer three questions at any moment: is it healthy, what is it doing, and what just changed. A system in MVP stage usually cannot answer any of the three without someone SSHing to a server.
What “done” looks like: structured logs that can be searched and filtered; metrics that capture request rate, error rate, and latency distributions at minimum; distributed tracing when the system has more than one service; alerts that fire on symptoms customers would notice, not on internal conditions engineers happen to find interesting; a dashboard that someone on-call can open at three in the morning and use.
The common shortcut: print statements written to stdout, a few log files on the server, and the belief that the team will notice if something goes wrong. The team notices when customers complain. By then the incident has usually been running for hours.
The cost in the first outage: mean time to detect measured in hours rather than minutes. Mean time to diagnose measured in guesses rather than data. The next outage is no easier because nothing was learned from the first one.
Gate 3: Data durability, tested
Backups are the feature that everyone claims to have and very few actually have in a usable form. An MVP typically has backups configured. A production system has backups that have been restored from, end to end, recently, under realistic conditions.
What “done” looks like: automated backups running on a defined schedule; backup retention that matches the recovery point objectives the business has actually committed to; periodic restore drills that prove the backup can be used; backups stored in a location that survives the loss of the primary region; encryption at rest with keys managed appropriately.
The common shortcut: a nightly database dump copied to a bucket that nobody has ever tried to restore from. The shortcut produces a file that will not actually restore cleanly because of a schema migration that ran two months ago, or because the dump format is incompatible with the new database version, or because the bucket credentials have rotated and the job has been silently failing for three weeks.
The cost in the first outage: data loss that cannot be recovered, measured not in hours but in business records that no longer exist. This is the outage that ends companies.
Gate 4: Rate limiting and abuse protection
An MVP is usually deployed with the assumption that users will be well-behaved. Production has no such assumption. Production has scrapers, credential-stuffing bots, customers who accidentally call an endpoint in a loop from a misconfigured integration, and occasional targeted abuse.
What “done” looks like: per-account and per-IP rate limits on every public endpoint; aggressive limits on authentication endpoints specifically; protection for expensive operations that could be abused to cause disproportionate load; clear error responses when limits are hit; a path for legitimate customers to request higher limits.
The common shortcut: no rate limiting at all, because no one has misused the API yet. This works until the day a customer’s integration goes into a retry loop, or a scraper finds the product, or a competitor’s security researcher notices that the signup endpoint has no limits.
The cost in the first outage: the product is offline for legitimate customers while the team figures out how to drop traffic from the abusive source. If the abuse is distributed, the outage is longer and more expensive.
Gate 5: A customer support diagnostic path
This gate is underrated because it is invisible during the demo. When a customer reports a bug, someone on the team has to be able to answer a simple question: what did the system do for that customer’s request, and why did it do that? In an MVP, the answer is usually “we do not know, can you send us a screenshot?”
What “done” looks like: request IDs that propagate through logs and surface in the user interface; an internal tool that lets support look up recent activity for a specific customer without database access; an audit log of customer-relevant actions, queryable by account; a documented runbook for the common support issues that have already been seen twice.
The common shortcut: no support tool at all, and every customer issue becomes an engineering escalation. This appears sustainable at five customers. It collapses at fifty.
The cost in the first outage: engineering time diverted from fixing the issue to answering individual customer inquiries. Response times drop. Customers lose confidence. The team burns out doing work that should have been handled by support.
Gate 6: Graceful degradation
An MVP usually fails hard when a dependency fails. A production system fails soft. When the payment provider is slow, checkout still loads but displays a clear message. When the search index is down, the product is still browsable. When the email service is rate-limited, actions that do not require email still work.
What “done” looks like: timeouts on every outbound call, appropriate to the operation; circuit breakers that stop hammering a failing dependency; fallbacks for read-path operations where stale data is better than no data; queues for operations that can be retried asynchronously; clear user-facing messaging when a feature is partially unavailable.
The common shortcut: synchronous calls to every dependency, no timeouts beyond the defaults, and the assumption that everything will be up. In the first real outage, a slow downstream service holds request threads, the application runs out of connection pool capacity, and the entire product goes down because one optional feature is degraded.
The cost in the first outage: total unavailability when partial availability was achievable. Every downstream service becomes a single point of failure for the entire product.
A maturity checklist
Before calling an MVP production-ready, walk through the following. Anything not honestly checked is a known risk, not a surprise to come.
- Authentication handles reset, rate limiting, and secure session management.
- Structured logs and metrics exist and are searched by real humans, not just stored.
- Backups have been restored from, end to end, in the last sixty days.
- Every public endpoint has rate limiting.
- Support can answer “what happened for this customer” without engineering involvement.
- At least one dependency has been artificially failed in staging to verify graceful degradation actually works.
What this framework is not
These six gates are not a complete production readiness checklist. They are the ones we see teams skip most often, with the most consistent downstream cost. There are others — security review, load testing, disaster recovery drills, compliance evidence collection — that matter for many organizations. Those belong in a longer checklist.
What these six have in common is that each one is invisible when things are going well and catastrophic when things are not. The pattern we see is that teams that honestly pass these gates before launch have small incidents that resolve quickly. Teams that skip them have large incidents that resolve slowly and leave scars on customer relationships.
The temptation to launch before these gates are closed is real. The market is moving, the investors are waiting, the competitor is shipping. We understand. But the honest conversation to have with your team is not whether the MVP is ready. It is which of these gates you are choosing to leave open, and what you are agreeing to pay when the first serious incident finds the one you wished you had closed.
Top comments (0)