Nobody Agrees What "Production-Ready" Means. Here's the Bar.

Before this essay says anything about anyone else, it should implicate itself: the phrase production-ready appears on thirty pages of this website, including the homepage. We are not observers of this problem. We are participants in it. And that is precisely why it seems fair to stop and ask what the phrase is actually claiming — because right now it is doing an enormous amount of work in developer marketing while meaning something slightly different to every person who reads it.

Ask five engineers what makes something production-ready and you will get tests, or observability, or a load test, or a security review, or a shrug and “it's running in prod, isn't it.” None of them are wrong, exactly. They are just describing different bars, which is another way of saying there is no bar. So here is an attempt at one that is small enough to remember and specific enough to fail.

The Category Error: It's Not About Your Code

The reason the phrase resists definition is that most people reach for it as a compliment about code quality — clean, tested, reviewed, well-structured. But code quality is not what the phrase is for. Plenty of beautifully written software is a catastrophe in production, and plenty of ugly software has been quietly serving customers for a decade without incident. If code quality were the measure, the correlation would be much tighter than it is.

Production-readiness is better understood as a property of a system in its worst hour. It describes not how the software behaves when everything works, but what your options are when something breaks at an inconvenient moment — which is the only time the property is ever tested. Nobody has ever needed their software to be production-ready on a good day. The whole concept only pays out during an incident, and it should be defined in terms of one.

That reframe is what makes a checkable bar possible. “Is this well built?” is an aesthetic judgment that two competent people can disagree on forever. “When this breaks at 2 a.m., what can you actually do?” has answers, and the answers are either yes or no.

The Bar: Four Questions

Every one of these is answerable in a sentence. If answering takes longer than that, the answer is no.

• Can you tell who did what? Not just authentication — anyone can add a login. The question is whether, after the fact, you can reconstruct which actor took which consequential action and when. Deleted records, permission changes, refunds, admin overrides. Without this, every incident involving a human decision becomes an argument about memory, and every support dispute is your word against a customer's.
• Can you tell what broke? An error your system swallowed is an error you will meet again. This is the difference between a log that says something went wrong and one that lets you find the specific request, the specific user, the specific failure, without redeploying to add a print statement. The bar isn't a fancy observability stack; it's whether the information you need already exists at the moment you need it, rather than being something you go add afterward.
• Can you undo it? Two halves, and almost everyone has only the first. The code half is a rollback: a specific, named procedure for putting yesterday's version back. The data half is a backup you have actually restored at least once, on purpose, as a drill. An untested backup is not a backup; it is a belief about a file. The number of teams who discover their restore path does not work while trying to use it is not small.
• Can someone other than the author operate it? The one that gets skipped, because it isn't a technical property at all. If exactly one person knows how to deploy it, where the credentials live, and which service to restart, then the system's availability is a function of that person's calendar. This is a real, everyday failure mode — not a dramatic one, just a vacation.

Most Software Clears the First Two and Fails the Last Two

This is the pattern worth naming, because it is remarkably consistent. Authentication and logging are build-time concerns. They live in the codebase, they get written while you are already writing code, they feel like programming, and a competent developer adds them almost reflexively. So most projects arrive at launch with a decent answer to questions one and two.

Rollback and operability are different animals. They are not features; they are procedures, and procedures live outside the repository in the part of the work that looks like paperwork. Nobody enjoys writing them, they produce nothing you can demo, and they only ever prove their value on the worst day of the quarter. So they get deferred, and the deferral is invisible — a system missing a rollback plan looks exactly like a system that has one, right up until the moment it doesn't.

That asymmetry explains most of the confusion around the phrase. Two teams can both say “we're production-ready” in good faith, one meaning “the code is solid” and the other meaning “we have rehearsed what we do when it isn't,” and they are describing genuinely different levels of preparedness with the same words.

Permission to Ship Anyway

Here is the part where this essay declines to be a scold, because the honest position is that shipping without clearing the full bar is frequently the correct call.

An internal tool used by four people who all sit near each other does not need an audit trail; you can just ask. A weekend project with no users has nothing to roll back to and no data worth restoring. A prototype whose entire purpose is to find out whether anyone wants the thing should absolutely not spend its first week on operational rigor for a product that may not survive contact with a customer. Insisting on the full bar in those situations is not discipline, it is procrastination wearing a high-visibility vest, and plenty of software has died of readiness it never needed.

The sin is not being below the bar. The sin is not knowing which line you are on — shipping something to paying customers while privately carrying a prototype's operational posture, and only discovering the gap during the incident that exposes it. Deciding “we are not doing rollback yet, and that is fine because we have three users and a database we could rebuild from scratch” is a legitimate engineering decision. Never having thought about it is not the same decision; it just resembles one until something goes wrong.

Which is also why this scales with stakes rather than with size. The moment the software holds something a person would be upset to lose — their money, their work, their data — the bar stops being optional, and it does not care whether your team is fifty people or one. A small tool with real customers owes more operationally than a large system with none.

The Uncomfortable Test

If you want to know where you actually stand, skip the checklist and try this instead: say your rollback procedure out loud, right now, in one sentence, without looking anything up.

Not the idea of one. The actual steps — what you run, where you run it, how long it takes, and how you would know it worked. Most people cannot do this, and the discovery is usually a genuine surprise, because there is a strong intuition that a rollback plan exists somewhere in the general vicinity of the project. It rarely does. There is a deploy script, and there is an assumption that deploying an older commit would probably work, and those two things together feel like a plan while being, precisely, not one.

The same test works on the other three. Who deleted that record last Tuesday? Which request threw the error the customer is describing? If you were unreachable for a week, could the thing be deployed? Four questions, four sentences. The ones you can't answer are the ones that will find you.

Why Any of This Matters

Defining the phrase is not a semantic exercise. “Production-ready” is the word we all use to decide when something is safe to put in front of people who are counting on it — which means a vague definition produces confident, unearned decisions at exactly the moment confidence is most expensive.

It is also worth saying that clearing the bar is not a one-time achievement you unlock and keep. Systems drift, procedures rot, and the person who knew how to restart the service leaves. A rollback that worked in March and has not been exercised since is an untested backup by another name. This is part of the real, ongoing cost of keeping live software alive — and one of the better arguments for keeping the operational surface small, in the same spirit as building software that can actually be finished. A bounded system with three dependencies is a system whose worst hour you can still reason about. A sprawling one is not, no matter how production-ready anyone declared it at launch.

So: four questions. Answer them honestly, decide deliberately which ones you are choosing to skip and why, and write the decision down somewhere your future self will find it. That is a meaningfully higher standard than the phrase currently carries — including, in fairness, on the thirty pages of this site that use it.