Production-ready software: the nine questions that carry your prototype through week two

The Tuesday after launch is the honest day. At launch everyone was watching and it was loud. By Tuesday nobody is watching. It runs, nobody has complained, and still the first thing you do in the morning is open the page to check that it is still there.

Listen to the checking. It knows something. Some part of you has worked out that “it runs” and “it holds” are two different things, and that you have only tested one of them so far.

The thing came together fast, and a large part of the code came out of an AI tool. That is exactly where the distance between “it runs” and “it holds” comes from, and that distance is called production-ready software. It is shorter than it looks. The list that makes that morning check unnecessary is nine questions long. Not ninety. You can work through it in an afternoon.

What is production-ready software?

Production-ready software is software that keeps working when nobody is standing next to it. That is the whole difference. A prototype needs you in order to run. A production-ready system runs while you sleep.

The industry term is production readiness, and the term has an image problem: it sounds like data centres, on-call rotations, a department you do not have. This particular misunderstanding is what costs small teams the most.

Whether your product feels right and sounds like you is a separate question, and I answered that one in “Testing vibe-coded software”. This piece is about the other half: whether the thing is still standing when you are not watching.

Why does the code keep getting better and the security does not?

The models got much better at writing code that works. Not one bit better at writing code that holds. The next release will not clear that up either. It is built in.

Veracode has been measuring this for two years: more than 150 AI models, 80 coding tasks, the same test every time. The result from March 2026 is two numbers you have to put side by side before they hurt. Syntax correctness now sits at over 95 percent. The code runs, almost always. The security pass rate sits at roughly 55 percent. And that one has been essentially unchanged for two years. Source: Veracode, 2026

Veracode’s own summary is the best sentence on the subject: two years of revolutionary model releases have moved the security needle from roughly 55 percent to roughly 55 percent.

One caveat, and you should have it: Veracode sells security testing. Their business model depends on code having holes. You have to factor that in. But 150 models, standardised tasks, a measurement series running two years: the methodology is not easy to dismiss. Two curves are diverging, and you only see it if you measure long enough.

Concretely: 45 percent of AI-generated code samples introduce a known OWASP Top 10 vulnerability. For Java it is more than seven out of ten. Source: Veracode, 2025 And here comes the clause almost everyone drops when they quote that number: this applies when no security guidance is given. An instruction is missing, that is all there is to it. Hold on to that clause.

The second number comes from Faros: two years of telemetry, 22,000 developers, more than 4,000 teams. Faros did not compare then against now. They compared, inside the same organisation, the stretches with little AI use against the stretches with a lot. Under heavy use, the ratio of incidents to pull requests is 242.7 percent higher. Source: Faros AI, 2026 Per pull request, that is the point: the volume is already divided out. Faros has a term for it that I rather like: acceleration whiplash. More goes out, and what goes out is broken more often.

The caveat belongs here too, and Faros supplies it themselves: this is a ratio, not a probability. A single pull request can be linked to several incidents, and not every incident traces back to the most recent change. A relationship, not a proof. And Faros sells engineering analytics, so the same caution applies as with Veracode.

Isn’t production readiness just for big companies?

No, the opposite. It is the one part of this work that stays small when you are small.

The 2025 DORA report has one finding that organises everything else: AI is an amplifier. It magnifies the strengths of functioning organisations and the dysfunctions of struggling ones. Source: DORA / Google Cloud, 2025 An amplifier turns up what is already there. Teams that have answered the nine questions get faster with AI systems. Teams that left them open break faster. Same technology, opposite direction.

Production readiness spent years being treated as a luxury for the big players. Own department, runbooks, three hundred items on a list. Small teams concluded the topic was not theirs.

That was a misunderstanding. The list is long at big companies because their system is big. Two hundred services, forty teams, nobody holds the whole thing anymore. Over there, the list replaces knowledge that no single person can carry.

You know your entire system. When an invoice comes out wrong, you know which file to open, and you do not have to go looking. That is the starting position a short list was made for. Nine questions, because your system is nine questions big.

What goes on the list?

Three blocks: what happens when it breaks, what happens when someone attacks it, what happens when you are gone. Three questions per block. Hence the nine.

The two numbers from earlier point at different blocks, and that matters. Veracode’s 45 percent point at block two, the security one. Faros points at blocks one and three: when things break more often, you need a way to notice and to get back. The second half of this list was always right. AI tools just made sure a lot more software exists that never went through it.

One rule first, otherwise the list does not work. Every one of these questions gets a yes or a no. If your answer is “well, sort of”, the answer is no.

Block 1: What happens when it breaks?

1. Do you find out before your customers do? The default state of freshly built systems: you learn about outages through an email from someone who is annoyed. An uptime check that knocks every five minutes and writes to you otherwise costs nothing. Ten minutes of work, and you are never again the last to know.

2. Can you go back? Is there a last state you know for certain was working, and can you get there in under five minutes? Have you actually done it?

3. Is yesterday’s data still there, and have you ever restored it? The second half of that question is the real one.

A backup you have never restored is not a backup. It is a hope with a file extension.

This is the point where it gets uncomfortable. Setting up a backup feels like being finished. Restoring it is the work nobody gets around to afterwards.

Block 2: What happens when someone attacks it?

Here is where that clause comes back: when no security guidance is given. The 45 percent are the result of nobody asking.

4. Are credentials sitting in the code? API keys, passwords, tokens. Pushed publicly once by accident, and the key is out. You cannot pull it back, only replace it. AI assistants like to write credentials straight in, because that is how it looked in the examples they learned from.

5. Who is allowed to do what, and is that checked on the server? The classic: the button is hidden in the frontend, but the server never asks. Anyone who knows the address walks in. Taking the sign off the door does not lock it.

6. What happens with garbage input? Negative numbers, empty fields, a novel in the name field, an emoji in the postcode. Validated on the server, not just in the browser.

Block two is the one where you are most likely to think you cannot answer it yourself. You can. You put the same AI system that wrote the code up against it. Do not ask “is this secure?”, you will get a yes. Say:

Here is the code. Find the three ways I can get at data that is not mine.

The role changes everything. It attacks better than it defends.

Block 3: What happens when you are gone?

7. Can someone else start it? If you are away for two weeks and it goes down: does anyone get in? Is there a page that says where it lives and how to bring it back up?

8. Do you know what it costs when a hundred people show up at once? Not whether it survives that. What it costs. The expensive moment is rarely the outage. The expensive moment is the invoice.

9. Where does the data live, and who is the processor? GDPR. Unpleasant, but it is the only question on this list where somebody can send you a letter.

A few items on this list can be changed later in an hour, others never again without a rebuild. Question nine belongs to the second kind. Why that line runs exactly where it runs is something I took apart in “Software design vs. software architecture”.

What is the most expensive mistake your system can make?

This question has no number, because it gives all nine of them their weight.

A broken appointment booking is annoying. An invoice with the wrong total is expensive. Customer data in the wrong email is existential. The same nine questions take on a completely different urgency depending on your answer.

The outage-cost figures you will find, by the way, mostly come from data centres with their own departments. For you the damage looks different. It looks like a customer who does not come back and does not tell you why.

Where to start

Start with question three. Restore your backup once. Once.

If it works, you know something about your system you did not know before. If it does not work, you have just found the most expensive mistake of your year while it still costs nothing. One question, one afternoon.

Going through the list is something you can do alone. For a few of the answers, the fixing then becomes its own job, question five and question nine above all. Those are about things you do not see, because you do not know they are there. That should not stop you from going through the list. It only changes what you do with it afterwards.

Those two curves are not going to converge. After two years of measurement there is little to suggest the next model closes the security gap. Question four already pointed at where this comes from: the examples the models learned from. A bigger model does not make those better. So everything else gets faster. The part that belongs to you stays the same size.

Nine questions. They do not multiply, however fast the rest gets.

And one Tuesday, you will not check.