You built your app with AI: what's missing before it can go to production

You described what you needed to Lovable, to Bolt, to v0, to Replit — or to ChatGPT, line by line — and within hours it existed. It works: the screens are there, the data saves, you showed it to someone and it worked there too. The question now is a single one — can I actually let people use this?This article isn't here to tell you that you did it wrong. It's here to tell you what separates what you have from something that holds.

First: what you built counts

There's a reflex among developers to write these things off as toys. It's the wrong reaction, for a practical reason: in a few hours you produced the thing that costs months on real projects and almost always comes out badly — a specification that runs. Not a requirements document, not a meeting: an object you can use, that demonstrates what the product has to do.

When I come into a project like this, that prototype is the first thing I read, and it's more useful than any statement of work. Knowing what to build is half the job, and that half is done.

The jump no tool makes for you

Tools that generate applications are very good at producing what you see: screens, fields, buttons, a flow that hangs together. They are structurally weak on what you don't see — and that is exactly where the difference between a demo and a product lives. There are six of them, and none comes out of a prompt.

1. Who sees what

If your app has more than one user, the decisive question is: what happens when someone changes a number in the browser address bar? In a demo, often, they see someone else's data. It's the most common flaw and the most serious one, because it never shows up by accident: it shows up the day a customer tries it out of curiosity. The rule "each person sees only their own data" has to be written in code and verified — not left to an interface that simply doesn't show the link.

2. Who holds the keys

Where does the code live? Who owns the account it runs on? And if that service changes its pricing or shuts down tomorrow, what do you actually have in your hands? It's the same question I ask people arriving from a project a supplier walked away from — and the answer matters more than the code: without access, nothing can be maintained.

The check is trivial, and it belongs today rather than the day you need it: download the project. Almost all these platforms allow it, or connect to a Git repository. If the file arrives, you're in a strong position whatever happens next. If you find out you can't, that's already the most important thing you'll learn today.

3. What happens when someone makes a mistake

Sooner or later someone deletes the wrong thing. That isn't pessimism, it's statistics. The question isn't if, it's where you restore it from. A backup nobody has ever tried to restore isn't a backup: it's a hope with a reassuring name.

Concretely: can you export the database, do you know where the file lands, and have you ever put it back at least once? Most of these platforms do have backups — often on the paid tier, often switched on and never verified. The gap between having one and knowing how to use it always shows up on the wrong day.

4. Costs that grow on their own

App-generation platforms charge by usage. With three people nobody notices; when real users arrive, the bill grows along a curve nobody chose. Look at it early, not when the invoice lands: sometimes staying is right, sometimes the math flips fast.

5. Changes that break what already worked

The warning sign isn't that the app has a bug: it's that adding one feature breaks another, and you only find out because a user tells you. You need automated checks on the few things that must never stop working — not on everything, just on those.

6. Who answers at three in the morning

While it's an experiment, nobody answers, and that's correct. The moment someone does their job on top of it, "it's down" becomes a problem with a clock attached. You don't need 24/7 cover: you need to know in advance who looks, where they look, and how long is too long.

The three questions that tell you where you stand

If you want a thirty-second diagnosis, it's these:

• If the service you built on shut down tomorrow, would you have the code?
• If a user changed a number in the address bar, would they see someone else's data?
• If someone deleted a table by mistake, where would you restore it from?

A single "I don't know" means the problem is already there. It just hasn't shown up yet — and these things always show up at the worst possible moment.

What you don't need

You don't need to start over, and be wary of anyone who proposes it without having read what you have: in my experience that's more often the convenient answer for whoever is quoting than the right call for whoever is paying. You don't need to stop using AI either — I use it every day, and I say so openly on AI in your company.

What you need is someone to decide what it may generate on its own and what it may not. New features, yes. The rules about who can reach which data, no — those get written and verified, because they're the only ones that, when wrong, throw no error: they just do damage, later.

Frequently asked questions