Where AI app builders stop: what's left before paying users

An app built in Lovable, Bolt or v0 can look finished well before it is. The screens work, sign-up works and a test card goes through. What's usually missing sits underneath, in the parts a demo never touches.

I'm not knocking the tools: some of our own repositories began as Bolt.new scaffolds, and a working demo in days is worth a lot. The gaps show up later, when a stranger signs up, pays, asks for a refund or opens a URL that isn't theirs.

What are the limitations of AI app builders?

Lovable, Bolt and v0 are good at the part of an app you can see: they turn a description into screens, flows and a basic database in an afternoon. What they mostly leave to you is the part a stranger tests:

• access rules enforced on the server
• live payments that survive webhooks, refunds and retries
• database changes you can replay
• separate staging and production
• email from your own domain
• error alerts that reach a person
• backups you've actually restored
• app-store rules, if you're going mobile
• accounts in your company's name

Most prototypes should be finished underneath, not thrown away.

Why does the demo work when production doesn't?

A demo runs on the happy path: one user (you), test-mode cards, your own inbox and a handful of rows you typed in yourself. Nothing in it is trying to break anything.

Andrej Karpathy, who coined "vibe coding" in February 2025, called it "not too bad for throwaway weekend projects." Simon Willison's post on what vibe coding means (opens in a new tab) pins it down as building software with an LLM "without reviewing the code it writes." Production is where somebody has to start reviewing it.

What does it take to get a Lovable or Bolt app to production?

Most areas below come with a check you can run without reading code. The builders ship fixes quickly, so compare your tool's current docs with anything here.

The database examples use Supabase. If you're on Lovable Cloud, which Lovable's docs (opens in a new tab) say is built on Supabase, look for the same settings inside Lovable.

Can one customer see another customer's data?

Logging in and being allowed to see something are different things. Plenty of prototypes handle the first and only fake the second: the interface hides other people's records, but the database would hand them to anyone who asked.

On Supabase, the safeguard is row-level security (RLS), rules inside the database about which rows each user may touch. Supabase's production checklist (opens in a new tab) is blunt: tables without RLS and reasonable policies let any client access and modify their data.

The switch being on isn't enough, either. In May 2025, Matt Palmer's statement on CVE-2025-48757 (opens in a new tab) reported inadequate RLS in 170 of 1,645 Lovable projects scanned, about 10.3%, exposing user emails, API keys and payment details. At the time, he said, Lovable's scanner checked that a policy existed, not that it was correct.

Lovable has tightened this since. Its explainer on its pre-publish security scan (opens in a new tab) says the scan now runs automatically and reviews RLS, though it doesn't analyze your code for logic flaws specific to your app. Whether each policy matches who should see what is still on you.

Supabase's page on API keys (opens in a new tab) adds that its service_role key and the newer sb_secret_ keys skip RLS entirely, so neither should ever reach the browser.

The check: log in as one test user, open one of their records and copy the URL. Paste it while logged in as someone else, or logged out. If the record shows up, that's a gap, and so is an admin page that opens for a customer.

Do payments survive live mode, refunds and retries?

A Stripe checkout is easy to add; the trouble starts in live mode. Stripe keeps test and live apart, as its docs on API keys (opens in a new tab) explain: each mode has its own keys, and objects such as products and prices don't carry across. An app still pointing at a test price looks fine in every demo, then fails the first time a real customer tries to pay.

Webhooks, the messages Stripe sends your app when a payment clears or a charge is disputed, are where the real bugs live. Stripe's webhook documentation (opens in a new tab) says the same event can arrive more than once and in any order, and a failed live-mode delivery is retried for up to three days. Each endpoint's signing secret also differs between test and live, so the one from testing won't verify real events.

An app that treats every webhook as new will eventually create two orders or send two receipts. What prevents it is plain bookkeeping: verify the signature, then record each event ID you've processed so repeats get skipped.

Refunds and disputes each need a path in the app, and so do renewals that fail. To test the refund path, buy something in live mode with your own card, refund it from the Stripe dashboard, and see whether the app notices by itself.

Is the data model shaped like your business?

Builders shape the database around the screens you asked for. The usual mismatches are one user per account when you sell to teams, prices stored in a way that can lose cents, and no clear line between one customer company's data and the next.

Schema changes also tend to be clicks in a dashboard. In production, each change should be a migration file in your repo, applied the same way to staging and production. Could someone rebuild your database structure from the repo alone?

Load your busiest list with far more rows than you have today; slow pages usually mean missing indexes. Supabase's JavaScript reference (opens in a new tab) also notes that projects return at most 1,000 rows by default, so a list that never asks for the next page quietly stops there.

Do you have staging, and can you roll back?

A lot of prototypes run off the builder's preview URL, where test records and paying customers share a single database. Production needs separate environments, each with its own database, and deploys that run the same way every time.

It also needs a rollback someone has actually tried. If a release breaks checkout, going back should take one step, not an afternoon of prompting.

Why aren't my sign-up emails arriving?

Try this: sign up with an address outside your team. If the app runs on your own Supabase project with no custom email provider, that confirmation email isn't coming. Supabase's docs on its built-in email sender (opens in a new tab) say it refuses to deliver to addresses outside your project's team and allows two messages an hour. It isn't meant for production.

The same docs list providers to use instead, including Resend, Postmark, AWS SES and SendGrid. Even then, the production checklist notes that sign-up emails are rate-limited by default to 30 new users an hour, which you can raise.

Then send from your own domain with SPF, DKIM and DMARC set up, and keep account emails apart from marketing mail, so newsletter complaints can't drag password resets into spam.

Who pays when bots find your sign-up form?

A public sign-up form attracts bots, and you pay for the emails, rows and API calls they trigger. Supabase's production checklist points to its CAPTCHA protection for sign-up, sign-in and password reset; turn it on, with sensible rate limits. If the app calls an AI API, put a spending limit, or at least a billing alert, on that account.

Will you hear about errors before your customers do?

In production, the person who hits an error is a customer who closes the tab and never tells you. You need monitoring that alerts a person (Sentry is a common choice) and logs you can search. Decide who gets that alert before launch, and make sure it isn't only you.

Have you ever restored a backup?

A backup you've never restored is a hope. Supabase's backup documentation (opens in a new tab) recommends that free-plan projects export their data regularly with the CLI and keep copies off-site; paid plans keep daily backups, seven days of them on Pro. Supabase's production checklist also warns that it may pause Free-plan projects with low activity over a 7-day period.

Two details catch people out: database backups don't include files uploaded through Supabase Storage, and the project is offline while a restore runs. Sometime this month, load a recent backup into a spare project and point a copy of the app at it.

Can a Lovable app go in the App Store?

Yes, but not as it stands. Lovable builds web apps, and its own FAQ (opens in a new tab) points to a PWA or a Capacitor wrapper to reach phones; the other route is a native client. Apple's App Review Guidelines (opens in a new tab) then add rules a web demo never meets: 4.2 expects more than a repackaged website, and 5.1.1(v) says any app with account creation must let people delete their account inside it.

Reviewers also need a demo login with your backend switched on. Digital features sold in an iOS app fall under the in-app purchase rules in 3.1.1.

Who owns the code, the accounts and the data?

The builders let you export your code or sync it to GitHub. Do it now, into an organization your company owns.

The accounts are harder. Domain, hosting, database, Stripe, email and app-store developer accounts all belong in your company's name, with at least two people who can get in. If the builder hosts your database, find out now how you'd get the data out.

The last kind of ownership is knowledge. Willison's golden rule, from the same post, is that he won't commit code he couldn't explain to somebody else. The founder's version: someone you trust can explain how your app decides who sees what, and what happens to a payment. If nobody can, you don't fully own it yet.

Should you finish it or rebuild it?

Founders often frame this as keep everything or start over, but the middle option is usually the right one. In a prototype a few months old, what's valuable is the product decisions, most of all the ones real users have already clicked through.

The code underneath is usually the cheaper part to replace. So ask which layer is wrong.

Signs you can finish what you have

• The data model matches how the business works.
• Login runs on a managed provider, and roles can be added to it.
• The code is in Git and builds outside the builder.
• What's wrong is mostly missing, like webhooks or monitoring, rather than built badly.

Signs the foundation needs rebuilding

• The data model is wrong for the business, and every screen reads from it.
• Access rules exist only in the interface, so fixing them means touching every query.
• Each prompt fixes one thing and breaks something else.
• The stack can't do what the product needs, like background jobs.

What to keep either way

Keep the parts users already validated and rebuild underneath them a piece at a time, a version of what Martin Fowler calls the strangler fig pattern (opens in a new tab). It's also how we approach Launch Engineering.

Questions founders ask

Is Lovable production ready?

Partly. The screens and flows can often go live much as they are, and Lovable now scans your database rules before you publish. Access rules that match your business, live payments, email, backups and account ownership are still yours to close.

Is Bolt.new or v0 production ready?

Same pattern. Both can publish a working app, but being online isn't the same as being ready for strangers' data and money. Run the ten checks below first.

Is Supabase OK in production?

Yes. It's Postgres underneath and runs plenty of real products. When a Supabase app goes wrong after launch, the cause is usually configuration: RLS policies, the default email sender, a plan without backups, a single account owner.

How long does it take to make a vibe-coded app production ready?

It depends on which gaps you have, and I'd be wary of anyone who quotes a number before looking at the app. Adding email, monitoring and backups is a far smaller job than changing a data model every screen depends on.

Do I need a developer after building with an AI app builder?

For a demo, no. Once the app stores customer data and takes payments, yes: you need someone who can explain how the risky parts work. When you compare developers, ask each one how they'd run the URL check and the refund test above.

Ten checks before you invite real users

1. A sign-up from an email outside your team lands in the inbox, sent from your own domain.
2. Logged in as one customer, you can't open another customer's record by changing the URL.
3. In Supabase, every table has RLS on with policies written for it.
4. The JavaScript your site loads holds no secret keys: nothing starting with sk_ or rk_ (Stripe) or sb_secret_ (Supabase), and no AI API key.
5. A live payment refunded from the Stripe dashboard updates the app by itself.
6. Staging has its own database, and test data never touches production.
7. You've restored a backup at least once, and you know uploaded files aren't in it.
8. A production error reaches a person, rather than sitting in a log.
9. The domain, repo, database, Stripe and developer accounts are in your company's name, and two people can get in.
10. If you're going mobile, users can delete their account inside the app.

Each no is a gap to close before strangers arrive. The Production Gap Checklist is a longer list across the same areas.

Paying users also have to find you. Before you spend on ads, track one real conversion, such as a paid order, end to end. Our Growth Engine work starts there.

I'm glad to run these checks with you. The free Production Gap Review is a 30-minute video call where we go through your app together. I then send you a written map of what's ready and what isn't. You can work through it on your own or hand it to whoever builds next.

If every answer came back yes, skip the review and send the invites.