Prototype to Production Is a Judgment Call, Not a Checklist

The demo ran clean. Five people used it, nobody hit an error, and the thing you were told would take a quarter and a hired team exists on your laptop right now. That is a real accomplishment and it deserves to be said plainly before anything else.

It is also the exact moment the work changes character, and almost nobody tells you that part.

What actually changes between a prototype and a production app?

The environment does. A prototype is tested by people who know how it is supposed to go, clicking carefully, in the order the demo expects. A production app is used by people who do not know or care how it is supposed to go, at the same time as each other, on bad connections, sometimes deliberately looking for the seams.

Nothing about your code changes at that moment. Everything about the conditions it runs under does.

The specifics are unglamorous and they all arrive within weeks. Someone signs up with an apostrophe in their email address. The network drops halfway through a payment. A retry hits an endpoint that was never safe to call twice, and now there are two orders on one card. None of that shows up in a prototype, because a prototype is never asked.

That is why "it works" and "it is ready" are different claims. The first is about the happy path. The second is a judgment about everything else, and judgment is the part AI has not been supplying.

Why does AI make the prototype-to-production gap wider?

Because it accelerates the part of the work that was already fast, and does much less for the part that was already hard. That shows up cleanly in the data. Sonar surveyed 1,149 professional developers, fielded in October 2025, and asked where AI had a positive impact. The answers fall in a straight line, and the line tracks distance from real users.^[1]

Twelve activities were measured. Not one of them inverts the pattern.

At the top, 89% say AI improved developer productivity. Time to market, 70%. Code quality, 58%. By the time the question reaches end-user experience it is 47%, defect rates 39%, and the frequency of outages 25%. The severity of outages, dead last, 24%.

Sonar's own reading of it is honest about what that means. "If you're shipping code that looks right but isn't reliable, you're not improving the user's experience or the long-term health of your codebase."^[1]

Worth saying plainly: Sonar sells code-analysis tooling, so they have a commercial interest in a story about unreliable AI code, and this is self-reported perception rather than measured telemetry. That second point is arguably a feature here, because the argument is about what builders can and cannot see from the inside.

The same shape turns up in a completely different dataset.

The 2025 DORA report, drawing on responses from nearly 5,000 technology professionals, found AI adoption relating positively to delivery throughput and product performance, and negatively to delivery stability.^[2]

Stability is the thing that only exists once there are real users. Which is another way of saying the gap this post is about is the gap the measurements keep landing in.

What does "looks done" actually hide?

Mostly it hides thresholds. Every one of the following exists in your prototype in some form, and each one is fine at one scale and not at another, with no alarm that sounds when you cross over.

• Auth that met the demo. It kept out people who were not trying to get in. Real credentials, session handling and permission boundaries are a different problem than a login screen.
• Data integrity under concurrency. Two people editing the same record was hypothetical last week. It is a Tuesday now.
• The first traffic spike. Not a capacity-planning exercise, just the ordinary fact that load arrives without notice and at a multiple of anything you tested.
• Observability. Something breaks at 2am. What do you actually look at?
• Rollback. A deploy goes wrong. How long until it is undone, and does anyone need to be awake for it?

None of that is a list of features to add. Each is a question about what threshold you are at and what is acceptable to risk while you are there. Good-enough auth for 50 beta users is a genuinely different thing from good-enough auth for 500 paying customers, and the dangerous part is that nothing in the app tells you which one you are running.

There is a specific reason AI-built prototypes hide these better than hand-built ones did. They look more finished. Clean interface, coherent data model, working routes, all the surface signals of a mature app, generated in an afternoon. The polish arrives before the structural decisions do, and polish is what people read as readiness.

Developers know this from the inside. In the same Sonar survey, 61% agreed that AI "often produces code that looks correct but isn't reliable."^[1] This is the gap between looking done and being done, and AI widened it by getting much better at the looking part.

Is the gap a checklist or a judgment call?

It is a judgment call, and this is the part worth being stubborn about. A checklist tells you what to consider. It cannot tell you what is acceptable for your app, your users, your data and your tolerance for being wrong. Those answers differ for a hobby tool and a system holding customer payment records, and the same checklist covers both.

Here is the strongest evidence that builders already know this: they are throttling by stakes, without anyone telling them to. In Sonar's survey, AI use runs at 88% on prototypes, 83% on internal non-critical software, 73% on customer-facing applications, and 58% on mission-critical services.^[1]

That 30-point drop is a judgment call happening at scale.

Nobody wrote a rule. Developers simply trust the output less the more it can hurt, which is exactly the reasoning the prototype-to-production pass formalizes.

What experience buys is knowing which prototype assumptions are safe to carry forward, which need hardening, and which need to be rebuilt before anyone depends on them. That is a review, not a sprint, and it is the thing that generating code quickly does not give you.

Where that leaves you

Your prototype earned its place. It proved the idea, which is the part most software never manages, and it proved it fast enough that the market question got answered before the engineering question got asked.

The next move is not to add the missing features, because the missing thing is not a feature. It is a pass over what you built by someone who has watched apps meet real users, asking which assumptions hold at the scale you are actually about to hit.

We wrote the questions that pass should answer in the production-readiness assessment. Run them against what you have. Most of the answers will be fine, and the two or three that are not are the entire reason to look.