Tools like Lovable, Bolt, Cursor, v0 and Replit can turn an idea into a working app in days. That is a real achievement, and a demo that works is the hardest part to get right. Real customers, real payments and real data ask more of an app than a demo does, though. This checklist covers what to review before you invite the public in, written so you can work through it whether or not you write code yourself.

1. Accounts, access and secrets

  • Who can see what. Log in as two different test users and try to open each other's records by changing the address in the browser. Each user should only ever see their own data.
  • Database rules. If your app uses a hosted database such as Supabase or Firebase, check that access rules (for example Supabase's row-level security) are switched on and actually restrict data.
  • Secrets out of the browser. API keys for payments, email or AI services must live on the server, never in code that runs in the visitor's browser.
  • Admin screens locked down. Admin pages should check the user's role on the server, not just hide the link.

2. Data and payments

  • Validate everything users send. Forms and API calls should reject missing, oversized or malformed input on the server.
  • Payments confirmed by the provider. Mark an order as paid only when your payment provider confirms it (for example through a Stripe webhook), not because the browser said so.
  • Backups you have tested. Turn on automatic database backups and try restoring one.
  • Personal data handled deliberately. Know what you collect, why, and where it is stored, and publish a privacy policy that says so.

3. Reliability

  • A staging copy. Test changes somewhere other than the live app, with its own database.
  • Automated tests for the important paths. Sign-up, login, checkout and anything that touches money should be covered by tests that run on every change.
  • Error monitoring. You should find out about errors before your customers email you.
  • Sensible hosting. The app should restart on its own after a crash and cope with a busy day.

4. Ready to grow

  • You own the code and the accounts. The code should be in a repository you control, and hosting, domain, database and payment accounts should be in your name.
  • Readable structure. Another developer should be able to find their way around. If the AI tool produced one enormous file or several copies of the same logic, tidy it before it spreads.
  • Fast on a phone. Run PageSpeed Insights on your main pages and fix anything in the red.
  • Accessible. Check that it works with a keyboard and that text has enough contrast.

Can you keep using AI tools?

Yes. The aim is not to stop using the tools that got you here; it is to put a safety net underneath them. With tests and automatic checks running on every change, you can keep experimenting, and the net catches changes that would break something customers rely on.

When to bring in an engineer

Consider a review before launch if any of these apply:

  • You are about to take payments or store sensitive personal information.
  • You are not sure whether one user could see another user's data.
  • New features from the AI tool keep breaking old ones.
  • You are planning to raise money, sell to larger customers, or hand the app to a developer.