From AI Prototype to Production: What Actually Has to Change

Something genuinely changed in the last couple of years. A person with a clear idea and no engineering background can now describe an app and have a working version of it by the evening. Screens, navigation, a database, sign-in.

Then they try to launch it, and everything stops. Not because the app is broken, but because it has never been asked to work for strangers.

We should be clear about what we are not saying. The prototype is not wasted work, the tools are not bad, and the usual advice to throw it away and start again is almost always wrong. What is missing is the part nobody can see on screen.

The one-user assumption

This is the big one, and it underlies most of the rest. When you build and test an app alone, every record in the database belongs to you. Every screen shows your data, every query returns things you are allowed to see, and nothing ever tests the question the app has never been asked: what happens when the person asking is not you?

In practice, access rules are often absent rather than wrong. The app asks the database for a record by its identifier and the database hands it over, because nobody told it not to. That is invisible with one account and obvious with two.

Two things need to be true. The database must refuse to return a record to someone who should not have it, enforced at the data layer rather than in the screen that displays it. And the keys your app uses must not include the kind that is designed to ignore those rules. We have written both of those up in detail: why an AI-built app lets one user read another user's data covers the rules, and the one key that ignores all your security rules covers the key that makes them irrelevant.

If you do nothing else from this article, do these two. They are the difference between an embarrassing bug and a disclosure you have to tell your users about.

Secrets that are not secret

A prototype needs API keys, and the fastest way to make one work is to put it where the code can reach it. The browser is where the code is.

What makes this hard to spot is that a key can be absent from your source files and still reach your users, because build tools copy environment variables into the files the browser downloads according to naming rules. The source is not what ships. The bundle is. Checking the built output, not the repository, is the only test that means anything.

And when a secret has been public, moving it is not a fix. It has to be replaced, because the old one is already out there in someone's cache.

What the app is allowed to believe

Prototypes trust the browser, because during development the browser is you. In production the browser is a stranger's computer running software you do not control, and anything it tells you is a claim rather than a fact.

Payments are where this gets expensive. The pattern an AI builder will usually produce is: send the user to pay, wait for them to come back, mark the order as paid. That works in a demo and fails in reality, because the user closing the tab, losing signal, or simply editing the request all produce the wrong answer. The payment provider has to tell your server directly, and that message is the only thing allowed to decide whether money arrived. We go through the whole pattern in the browser is not allowed to tell you a payment succeeded.

The same principle generalises. Prices, totals, permissions, anything that matters: decided on the server, re-checked on arrival, never taken on trust from the thing the user can edit.

What happens when it goes wrong

A prototype is written for the path where everything works. Real users find every other path within a week: the payment that half-completed, the upload that timed out, the form submitted twice because the button did not look like it did anything, the network that dropped between two steps that were supposed to happen together.

What production needs here is not glamorous. Operations that can be safely repeated without duplicating their effect. Errors that reach you rather than dying silently in a user's browser. Enough logging to answer the question a customer will eventually ask about what happened to their order. Any app that works offline makes this harder again, which is its own topic in offline mode is easy, syncing afterwards is the hard part.

The honest summary is that production is mostly the unhappy paths. The happy path is the part you already have.

Getting it out, and getting the next one out

There is a last category that has nothing to do with code quality: the machinery of shipping. Somewhere to run it that is not one person's laptop. A way to release an update without hand-copying files. A copy of the app you can break safely. Backups you have actually restored from at least once. If it is a mobile app, store review, data-safety declarations and signing keys, which we cover end to end in shipping a React Native app to Google Play.

This is the part people skip, and the cost arrives three months later, when a small fix takes a nervous afternoon because nobody is sure what deploying will break.

Where to start

If you have a prototype and a launch date, work in this order. The sequence matters: the early items are the ones that cause harm you cannot undo.

1. Make two accounts and try to read one's data from the other. Do this before anything else, because the answer decides how urgent the rest is.
2. Search the built bundle, not the source, for every key you use. Rotate anything that is already public.
3. Find every place the browser tells the server something important, especially about money, and move that decision to the server.
4. Walk the three or four ways your main flow can fail halfway, and decide what the app does in each.
5. Get it deployed somewhere that is not a laptop, with a way to release again without ceremony.
6. Only then, go back to features.

A faster version of this triage, written as a checklist, is in seven problems we check first. If what you actually need is a number rather than a plan, what decides the cost of finishing a half-built AI app explains what moves it, and why two apps that look identical can be a fortnight apart.

The part worth keeping

None of this is an argument against building with AI tools. Getting to a working prototype in a weekend is a real advantage: you have proved the idea and skipped the slowest, most speculative part of software.

What has not changed is that production software is mostly about what happens when things go wrong, and that work has never been visible from the screen. The prototype was the easy ninety per cent. Knowing precisely what the other ten per cent contains is what turns an alarming unknown into a finite, plannable piece of work.