An AI-built app is usually not ready for customers because it has been optimised to demo, not to operate. The screens work, but there is no access control model, no error handling, no data retention policy, no billing edge cases, no observability and no support process. Those nine gaps are what separate a prototype from a product someone will pay for and keep paying for.
This is not a criticism of Lovable, Bolt, Replit or Cursor. AI builders have collapsed the cost of getting from idea to working software from months to days, and that is genuinely the biggest shift in product development in a decade. The problem is what happens next: founders treat the demo as the finish line, put it in front of paying customers, and discover the last 20% of the work is where all the commercial risk lives.
Prototype-ready and customer-ready are different bars
Prototype-ready means the happy path works when you drive it. Customer-ready means the unhappy paths are safe when a stranger drives it — at 2am, on a slow phone connection, with a card that declines, after a page refresh, with their colleague logged into the same account.
The honest test is this: if a hundred people you have never met signed up tomorrow, what would break, and would you know it had broken? Most AI-built apps fail the second half of that question before they fail the first. There is no logging, no alerting, and no error tracking, so the first signal of failure is a customer email — or, more often, silence and a churn.
The nine gaps I find in almost every AI-built app
I audit these builds regularly. The same list comes up nearly every time.
1. Authorisation, not just authentication. Login works; row-level security does not. Users can often read or modify records that belong to other accounts by changing an ID. 2. Input validation. Client-side checks exist, server-side ones do not. 3. Error states. The UI assumes success — no empty states, no retry, no failure messaging. 4. Data model drift. Tables were added prompt-by-prompt, so the same concept exists in three places with three names.
5. Billing edge cases. Signup and checkout work; failed payments, refunds, plan changes, proration and cancellation do not. 6. Email and notification deliverability. Transactional email sends from an unverified domain and lands in spam. 7. Observability. No structured logs, no error tracker, no uptime monitoring, so mean time to detection is measured in days. 8. Legal and privacy surface. No privacy policy, no data retention rule, no deletion path, no processor list — a problem the moment you sell to a business. 9. Support and operations. Nobody has decided who answers the first angry email, or from what inbox.
Why AI builders produce these gaps by default
An AI builder responds to what you ask for. Founders ask for features, because features are what they can picture. Nobody prompts "add a data retention policy and a deletion endpoint", so nobody gets one.
The second cause is that non-functional requirements are invisible in a demo. Security, reliability and observability have no screen. They produce no screenshot to show an investor. So they are the last things added and the first things cut, even though they are the things that decide whether the product survives its first hundred customers.
The third cause is accumulated context loss. Long AI build sessions drift. Code that was consistent at prompt 20 is inconsistent by prompt 200, because each change is made against a partial view of the system. Nobody is holding the architecture in their head, and the AI is not holding it either.
What to fix first, in order
Fix in risk order, not in effort order. Start with anything that could leak a customer's data: row-level security policies on every table, server-side authorisation checks on every write, and secrets moved out of client code. This is a one-to-three-day job on a typical AI-built app and it removes the failure mode that ends companies.
Second, fix money: make the billing lifecycle complete, including failed payments, cancellations and upgrades. Third, fix visibility: error tracking, structured logging and an uptime check, so you know about failures before your customers tell you. Fourth, fix the data model: consolidate duplicated concepts before you have real data to migrate.
Everything else — performance, polish, test coverage, refactoring — comes after. Most founders do it in exactly the reverse order, which is why they end up rewriting.
What this looked like in practice
At Wocal I built and ran the product through to a £2.7M pre-money valuation with 300+ venues on the platform. The difference between the version that got us the demo and the version that could take real bookings from real venues was six weeks of work that produced zero new screens: permissions, payment edge cases, monitoring, and a support workflow that meant a broken booking got fixed in minutes rather than discovered a week later.
That is the work I now do for founders who have an AI-built app and a waiting list. The prototype earned the attention. The production pass earns the revenue.
Where to go next
If you want the full gate-by-gate list, read the AI MVP production readiness checklist. If your concern is specifically security, read the hidden cyber security risks inside AI-built applications. If you want to understand the whole journey rather than the individual fixes, start with from prompt to production.
If you would rather not run this yourself, this is exactly what an MVP development engagement or a fractional CPO retainer covers.
Frequently asked questions
- Is a Lovable app good enough to launch?
- A Lovable app is good enough to validate demand, run a pilot, or raise on. It is usually not good enough to take payments from strangers until authorisation, billing edge cases, observability and a data deletion path have been added — typically two to four weeks of focused work.
- How long does it take to make an AI-built app production ready?
- For a typical single-journey product, two to four weeks. Security and authorisation take one to three days, billing lifecycle a few days, observability a day, and the rest goes on data model consolidation, error states and support process.
- Do I need to rewrite my AI-generated app?
- Almost never. Rewrites are usually the most expensive way to fix a problem that is really about missing non-functional requirements. Hardening the existing build is faster and keeps the validated behaviour you already have.
- What is the biggest risk in an AI-built application?
- Broken authorisation — users being able to read or change other accounts' data by manipulating an ID. It is the most common flaw, the easiest to exploit, and the one with the worst consequences if you are handling customer or payment data.
- Who should fix a prototype that is not production ready?
- Someone accountable for the commercial outcome, not just the code. That is the role of an AI product recovery or assurance lead: prioritise fixes by business risk, ship them in order, and confirm the product can survive real customers.