What Production-Ready Actually Means

Launchable Is Not the Same as Production-Ready

A launchable app is one that runs. A user can install it. They can sign up. They can use the main features. On the happy path — when everything goes right — the app does what it's supposed to do.

A production-ready app does all of that, and also survives the world.

These are not the same thing, and the distance between them is enormous.

The world is full of things that go wrong. A user's network drops in the middle of a payment. Their phone storage fills up. Their token expires while they're mid-flow. A database query takes too long because the database is busy. A third-party service goes down. An iOS update changes how a permission works. A user enters a name with an emoji in it that breaks something.

A launchable app might handle one or two of these. A production-ready app handles the ones you can predict, fails gracefully on the ones you can't, and (this is the part most people skip) makes sure somebody finds out when it does.

The distinction is not about polish. It's about whether your app can be trusted to operate without someone watching it manually.

What "Production-Ready" Actually Contains

In our experience, an app is production-ready when about eight things are in place. None of them are visible in the demo. All of them affect what your app does once it leaves the developer's laptop and meets real users.

1. Monitoring. Something is watching whether the app is up, whether requests are succeeding, whether response times are reasonable. Not "we'll check it manually" — something automated, looking at your app the same way it would look at a server.

2. Logging. When something goes wrong, there's a record of what happened. Not just on the user's device, where you'd need to ask them to send you something — on a system you can read. Logs are how the developer figures out, hours after the fact, why a user saw what they saw.

3. Error handling. Not "the app shows an error message" — the app handles the error. It tells the user something useful. It doesn't lose their work. It doesn't silently fail. It doesn't leave them on a blank screen wondering what to do.

4. Alerting. When something goes wrong, someone gets notified. A real person, on a real device, who can do something about it. The default state in most launches is that nobody finds out anything is wrong until a user complains.

5. Backups. If the database died right now, how much would you lose? A production-ready answer is "the last few minutes". A launchable answer is "all of it, or we're not sure".

6. Rollback. If the version you just shipped is broken, can you go back to the previous version quickly — within minutes, not hours? A production-ready deploy is one you can reverse.

7. A runbook. A written document — even a short one — that explains what to do when specific things go wrong. The login service is down: here's how to check. Payments are failing: here's how to diagnose. The runbook is what makes the difference between a calm Friday and a panicked one.

8. On-call clarity. Somebody — and somebody specific — knows they're responsible if the app breaks at 2am. This isn't paranoia; it's the difference between "we'll figure it out" and "we'll fix it".

You don't need to understand the engineering behind any of these. You need to know whether they exist. Most launchable apps have one or two. Production-ready apps have all eight.

The Cost Gap

Here's the part that catches buyers off guard.

A launchable app and a production-ready app can differ in price by 50% to 100%, and the difference is invisible in the demo.

The launchable app looks the same as the production-ready app from the outside. The screens are the same. The features are the same. The user experience, on the happy path, is identical.

What's different is the eight things above — which add real work. Monitoring takes setup. Logging takes thought, because the wrong kind of logging can leak sensitive data. Error handling has to be designed feature by feature. Backups need a plan, not just a checkbox. Rollbacks need infrastructure that supports them. The runbook has to be written. The on-call plan has to be agreed on.

None of this is visible to a buyer flipping through a demo. So when one developer quotes $12,000 and another quotes $22,000 for the "same" app, the buyer often chooses the $12,000 quote without realizing they're choosing the launchable version of the same product.

The $10,000 difference is, almost always, the difference between an app that can be left alone and an app that needs to be watched manually.

We cover the broader skill of reading quotes carefully in how to read a developer's estimate. The production-readiness conversation is one specific case of the broader one: the parts that aren't visible are often the parts that matter most.

The Single Most Expensive Thing People Skip

If we had to pick one of the eight things that gets skipped most often and costs the most when it's missing, it would be observability — the combination of monitoring, logging, and alerting.

Without observability, every other safeguard is wishful thinking.

A backup strategy you've never tested isn't a backup strategy; it's a hope. A rollback procedure you've never used isn't a rollback procedure, but a fairytale. An error-handling pattern that fires silently isn't error handling — it's the absence of one.

The thing that turns these from theories into actual capabilities is observability. You know the backup works because you can see, in the dashboard, that it ran last night. You know the rollback works because you can see, in the deploy logs, that a previous version is still available. You know the error handling fires because you can see how often it fires and what it catches.

When the buyer asks

the single most useful proxy question is:

If the answer is "we'd notice" or "users would tell us", you have a launchable app. If the answer is "I'd get a notification on my phone, and the dashboard would tell me exactly what's failing", you have something close to production-ready.

The cost of adding observability after launch is roughly 2–3x what it costs to build it in. The reason is that retrofitting requires changing code that wasn't designed to be observed, in dozens of places, while the app is live. Building it in means adding it once, at the layer it belongs in, before the rest of the app is layered on top.

This is why "we'll add it later" almost always means "we'll pay more for it later, much later, after a few painful incidents".

What to Negotiate Before Signing

If you're about to sign a contract for an app to be built — or for a major update to an existing one — there are a few specific questions that will tell you whether you're getting launchable or production-ready.

Is monitoring included? What service? Who configures it? A clear answer: "Yes, we'll set up [specific tool], and we'll wire up alerts for these specific failures." A red-flag answer: "We can talk about that later", or "It's not really needed for the size of app you have".

What happens when something goes wrong in production? Who finds out, and how fast? A clear answer: a named person, an automated path, a reasonable expectation of detection time. A red-flag answer: a vague reference to "checking on it" or "users will let us know".

What's the backup strategy? When was the last time you actually restored from a backup on a different project? The second part of that question matters more than the first. Lots of developers set up backups they've never verified. The ones who've actually restored from one know the procedure works.

If the version you're about to ship has a critical bug, how long does it take to roll back? A production-ready answer is "a few minutes, automated". A launchable answer is "we'd push a fix forward as fast as we can". One of these is a real safeguard; the other is hoping the fix works.

What's the runbook plan? If the answer is "we don't really do runbooks for projects this size", you can decide whether that's acceptable to you — but at least you know.

None of these questions are hostile. A developer who's used to building production-ready apps will have ready answers. A developer who isn't will reveal it in how they hedge.

The "We'll Add It Later" Trap

Almost every shortcut on production-readiness gets the same justification at the time: we'll add it later.

We'll add monitoring once we have users. We'll add error handling once we know what kinds of errors happen. We'll write the runbook once we know what goes wrong. We'll set up alerting after launch. We'll plan the backups when we have data worth backing up.

In a small fraction of cases, this is reasonable. A truly experimental product — a prototype meant to teach you whether to build the real thing, the kind we describe in you bought an MVP — what did you actually get — can legitimately defer these. Nobody is depending on a prototype.

For everything else, "we'll add it later" tends to mean "we'll add it after an incident proves we should have added it sooner". The incident is the teacher.

This isn't always catastrophic. Sometimes the incident is small — a few hours of confusion, a handful of frustrated users, an apologetic email. Sometimes it's worse — a payment outage nobody noticed, data loss because backups were untested, a security issue that went undetected because nothing was watching. The size of the incident is the cost of the deferred work, paid in retrospect, with interest.

The cleanest way to avoid this is to negotiate production-readiness as part of the original scope, not as a phase two. Even if the budget is tight, naming the eight items and choosing which ones to defer is a different exercise from skipping the conversation entirely. The first leaves you with a known gap. The second leaves you with a surprise.

What Production-Ready Doesn't Mean

It's worth being clear about what production-ready doesn't mean, because the term sometimes gets used to imply more than it does.

Production-ready doesn't mean bug-free. Every app has bugs. The difference is whether the app and the team can detect and respond to them — not whether they exist.

Production-ready doesn't mean scaled. An app can be production-ready for 1,000 users and not for 1,000,000. Scaling is its own dimension. Most early-stage apps don't need to be scaled-ready; they need to be production-ready for the load they actually have.

Production-ready doesn't mean compliant. If your app handles regulated data — health, finance, anything subject to specific legal frameworks — there are additional requirements beyond the eight items above. Production-ready is the engineering floor. Compliance is a separate, regulatory floor.

Production-ready doesn't mean done. It means the app can be operated without constant manual oversight. The work of running an app — improving it, evolving it, responding to what users do with it — continues forever.

Where to Go From Here

If you're about to launch an app: ask the question. Not "is it production-ready?", which most developers will say yes to reflexively, but the specific version: which of the eight things do we have, and which are we deferring? The answer will be clearer and more useful.

If you've already launched and you're not sure: a one-day audit can tell you. Ask a developer — your current one, or an independent one — to go through the eight items and tell you which are in place. This isn't expensive and is often the most useful single thing a buyer can commission in the first six months of an app's life.

If you've launched and something has already gone wrong silently: don't wait. The cost of fixing observability after one incident is the same as fixing it after five. The incidents compound; the fix doesn't get any easier.

The pattern most apps follow — launchable in month one, production-ready by month six, after enough things have gone wrong to motivate it — is normal and survivable. But if you can get to production-ready earlier, the painful learning curve compresses dramatically, and the next stage of your app's life starts on much firmer ground. We touch on what that next stage looks like in the first-birthday review piece — by year one, production-readiness is no longer optional, and the apps that reach it deliberately end up with very different futures than the ones that limp into it after incidents.

You don't need to know the engineering. You just need to know that "launchable" and "production-ready" are not the same word — and that the gap between them is the part of the bill people most often skip and most often regret.