Lovable, Bolt, Cursor and Replit are genuinely good. We use the same class of tooling every day, and anyone telling you otherwise is defending a billing model.
What they are good at is getting a working thing in front of a real person in days instead of months. That is not a toy achievement. It is the hardest part of starting, and it used to cost thirty thousand pounds to find out whether anyone wanted what you were building.
What they do not do is make the thing safe to charge money through. That gap is where we get called, usually in the same week somebody's first real customer signs up.
This post is what is in that gap, what it costs to close, and how to work out which side of it you are on.
What an AI builder actually hands you
A front end that looks right, a database it designed for you, and enough glue between them that the happy path works.
That is a real asset. The screens are often decent, the data model is often close, and the code is usually readable. When we take one of these over we keep it far more often than we throw it away.
What is missing is not features. It is everything that only matters when the app stops being used by you and your three friends:
- Rules the database itself enforces, rather than rules the interface politely follows
- Money handled on the server, where the customer cannot change the number
- Secrets that are not sitting in the JavaScript anyone can read
- A backup that has been restored at least once
- Behaviour in the cases a demo never reaches, like a declined card or a double-submitted form
None of that is visible from the outside. The app looks finished. That is the dangerous part.
The five things that break first
In the rescue work we do, the same five come up almost every time, roughly in this order.
1. Anyone signed in can read everyone's data
This is the big one, and it is the one people are most surprised by.
AI builders tend to filter data in the interface. The screen asks for this user's orders, and the screen is told to show only those. But the database will happily hand over any row to any signed-in request, because nobody told it not to. Change the ID in the URL and you are looking at somebody else's account.
The fix is row-level security, written so access is enforced at the database and the interface cannot override it. It is not difficult work. It is just work nobody did, because the app behaved correctly without it.
Test yours now: sign in as two different accounts in two browsers, and try to reach the first account's records from the second by editing the URL.
2. Keys shipped in the front end
API keys for Stripe, OpenAI, a mail provider, sometimes the database itself, bundled into the JavaScript the browser downloads.
Anyone can read them. Not metaphorically: open the developer tools, search the bundle, there they are. We have found live payment keys this way more than once.
The fix is moving them to environment variables on the server and rotating anything that ever shipped, because a key that was public for a week has to be treated as a key somebody has.
3. Prices the customer can set
If the amount charged is sent from the browser, the amount charged is a suggestion.
The server has to decide what something costs by looking it up, never by trusting what arrives. The same goes for quantities, discount codes and anything else with a number attached. And the webhook that tells you a payment succeeded has to be verified as genuinely from Stripe, or anyone who knows the URL can tell your app they have paid.
4. Nobody has ever restored the backup
Plenty of apps have backups switched on. Almost none have had one restored.
An untested backup is a belief, not a safeguard. We restore one in front of you and time it, so you know both that it works and how long you would be down.
5. The cases a demo never hits
Refunds. Declined cards. A form submitted twice because the first click seemed slow. A password reset that lets you take over an account. A file upload that accepts anything of any size.
These are not exotic. They are simply the things that do not happen while you are clicking through your own app to see if it looks right.
Fix it or rebuild it?
Almost always fix it.
We rebuild when the data model is wrong — when the way information relates to itself cannot support what the product now needs to do. Everything built on top of a broken schema has to be rewritten anyway, so you are not saving anything by keeping it.
If the data model is sound, and it usually is, keeping the codebase is faster, cheaper and less risky. It also keeps the behaviour your early users have already learned, which is worth more than most founders think.
Anyone who looks at an AI-built codebase and immediately recommends a full rebuild is quoting their preference, not your situation. Ask them which part of the data model is wrong. If they cannot answer, the answer is that it is not.
What it costs
Our kickoff sprint is £1,950 for two weeks, and on a rescue it covers the five areas above: authentication and sessions, database access rules, secrets and keys, payments, and backups you have watched restore. It ends in a written report saying what we found, what we fixed, what is left and what the rest would cost. The report is yours whether or not you carry on with us.
If the gap is bigger than two weeks, the rest carries on inside the subscription at £4,500 a month, which is also how most people get the next features built once the app is safe. Subscribe within 30 days of the sprint and the whole £1,950 comes off your first month.
If what you need is genuinely smaller than a sprint, we will say so and quote it as a one-off. That happens maybe one time in five and it is a perfectly good outcome.
Start by finding out where you stand
You do not need to buy anything to know how exposed you are.
Our production readiness check is eight questions, takes about two minutes, and gives you a score and the specific things to fix in the order they matter. No call, no sales follow-up you did not ask for.
If you would rather we just looked, send us the code and we will come back within two working days with a written review of what we found. I do those myself.
Either way, the thing worth internalising is this: the demo working is not the same as the product being safe. The gap between them is a known, bounded piece of work. It is far cheaper to close it the week before your first real customer arrives than the week after.
