A pilot does not decide an aircraft is ready by looking at it and forming an impression. They run a list, out loud, in the same order, every time — including on the thousandth flight. The list exists because judgement under time pressure is unreliable in exactly the ways that matter, and because "it looked fine" is not a transferable claim.

Software has no equivalent standard. "Production ready" means whatever the person saying it believes it means, which is why the phrase survives contact with two people who disagree without either of them noticing. Here is a version you can actually hold people to.

The eight statements

Each of these is either true or false today, and each is answered by someone showing you something rather than telling you something.

  1. Someone other than the author can put a change live, following a written process. Demonstrated, not asserted. Watch it happen once.
  2. We know within minutes when the product is broken, without a customer telling us. Ask to be shown the alert. If the answer describes intentions, the answer is no.
  3. Sign-up and payment are checked automatically before anything goes out. Not everything — these.
  4. We can undo a bad release in under an hour. Ask when this was last done. "Never had to" is a different answer from "last month, took twenty minutes".
  5. Customer data is reachable only by people who need it, and we can list them. Ask for the list. If producing it takes a week, that is the finding.
  6. We could restore the product if the database were lost today. Backups existing is not the claim. The claim is that a restore has been tested.
  7. A new engineer can have the product running and ship something small within a week. The number from question one of Seven Questions to Ask Your Developers.
  8. How the product is put together is written down, and it is current. One or two pages beats a wiki nobody has opened since March.
Close-up of aircraft throttle controls in a cockpit
Close-up of aircraft throttle controls in a cockpit · Pexels

What this list deliberately leaves out

It says nothing about test coverage percentages, frameworks, cloud providers, or code style. Those are real engineering concerns and they are not yours. Every statement above describes an outcome a business cares about: can we ship, do we know when we are broken, can we undo it, can we recover, can we grow the team.

This is the important property. A standard written in outcomes can be held by someone who does not write code. A standard written in technical means cannot, which is precisely why so many contracts contain the phrase and so few contain the definition.

A vendor cannot fail to meet a standard you never wrote down. Neither can your own team.

Where to put it

The list is worth very little as a one-off conversation and quite a lot as a fixture. Three places earn their keep:

  • In contracts with agencies and contractors. Attach it. "Production ready as defined in Appendix A" converts an argument at the end of an engagement into a checklist at the start of one.
  • In your definition of done for anything customer-facing. Not every ticket — the features that carry the promise.
  • In your board materials, once a quarter. Eight statements, green or red, with dates against the red ones. This is the cheapest technical reporting you will ever produce, and investors read it happily.

How to run it the first time

  1. Send the eight statements to whoever builds your product, in advance. Surprise produces defensiveness, and you want accuracy.
  2. Go through them together, asking for a demonstration of each rather than an assessment. "Show me" is the entire method.
  3. Mark each green, red or "we think green but have not checked". The third category is where the interesting problems live.
  4. Pick the two reds with the worst consequences — usually data access and restore — and date them.
  5. Re-run it quarterly. It takes under an hour once it exists.

Why this is the cheapest thing on your list

Every item above is a few days of work at most, and several are an afternoon. None requires rebuilding anything. Together they are close to the whole difference between a product one person operates and a product a company owns — the transition that everything else on this blog circles around.

And they compound in the right direction. The same eight statements that make your team faster are the ones investors probe in technical due diligence, the ones that shorten onboarding for every hire, and the ones your first CTO would otherwise spend their first quarter establishing. Doing it before they arrive is the same work at a better time.