Your app was built with an AI tool: is it ready for real customers?

The tools did their job

Lovable, Bolt, Replit, Cursor, v0 and tools like them are genuinely useful. They let a founder or a small business get from an idea to something people can click on without hiring a team first, and that's a real achievement. A working prototype answers the most important question: does anyone want this?

The catch is that "it works when I try it" and "it's safe to run a business on" are different tests. These tools are good at producing screens and features that do what you asked. They're less likely to raise the things you didn't ask about: who else can see a customer's data, what happens when a payment fails, or how you'd recover if the database was wiped. None of that shows up in a demo, so it's worth checking deliberately.

What to check before real customers arrive

These are the areas worth checking first in any app that's about to take real payments or hold personal data. Not every app will have problems in all of them, but each one is worth a definite answer.

Secrets and API keys in the front end

Anything shipped to the browser can be read by anyone who opens the developer tools. Check whether secret keys for your database, payment provider, email service or AI provider are sitting in front-end code or in environment variables that get bundled into it. A publishable key is meant to be public; a secret key is not. If a secret has ever been exposed, it needs rotating, not just removing.

Database access rules

If your app talks to the database directly from the browser, as Supabase apps are designed to, that's fine only if the database itself enforces who can read and change what. On Supabase that means row-level security switched on for every table, with policies that actually restrict each user to their own rows. Check by logging in as one test user and trying to fetch another user's records. If you can, so can anyone.

Sign-up, login and password reset

Check that email verification works, that password reset links expire and can only be used once, that the reset flow doesn't reveal which email addresses have accounts, and that admin pages check the user's role on the server rather than just hiding a button. Also check what happens to a session when someone logs out or changes their password.

Payments and webhooks

Payment providers such as Stripe tell your app about successful payments, renewals and refunds by calling a webhook. Your app should verify the signature on every webhook so nobody can fake a "payment succeeded" message. Check, too, that a repeated webhook doesn't grant access twice, that failed and cancelled payments actually remove access, and that the app doesn't decide what someone has paid for based on anything the browser sends.

Backups

Find out whether backups exist, how far back they go, and whether anyone has ever restored one. On some hosting plans backups are limited or not included. A backup you've never restored is a hope, not a plan.

Tests

If every fix seems to break something else, the app probably has no automated tests. That's normal for a prototype, but it gets expensive once customers depend on it. A small set of tests around the things that matter most, such as sign-up, payment and access to data, makes every later change safer.

Code nobody understands

AI tools can produce a lot of code quickly, and it's easy to end up with duplicated logic, unused files and several ways of doing the same thing. Check whether anyone, human or otherwise, can explain how a request flows through the app. If the answer is "I keep asking the AI until it works", that's a sign the codebase needs tidying before it grows further.

Hosting, costs and limits

Check which plan the app is running on, what its limits are for database size, requests, emails and AI calls, and what happens when you hit them. Some limits fail quietly. If the app calls an AI model, check there's a spending cap, so a busy week or a misbehaving loop doesn't produce a surprise bill. The same cost and data controls apply when adding AI to existing business systems.

UK GDPR basics

If you hold personal data about UK customers, you need a privacy notice that says what you collect, why, and who processes it. Check where your database and any third-party services store that data, since it isn't necessarily the UK or EU unless you chose it, and whether your providers' terms cover that. You should also be able to find and delete one person's data when they ask. The ICO's guidance for organisations is the place to start.

Review, fix, tidy, then keep building

When founders find problems like these, the first instinct is often to start again "properly". A rewrite is rarely the right first answer. Your app already captures what customers want, and rebuilding it from scratch costs time and money you could spend on customers. In most cases it's better to work in this order:

1. Review: find out what you actually have, where the data lives, who controls each account, and which risks are real. The output is a written list ranked by severity.
2. Fix the critical security issues: exposed secrets, open database access, unverified webhooks and broken access checks come before anything else.
3. Make it maintainable: put the code under version control in your own account, add backups, monitoring and a repeatable deployment, write tests around the parts that matter, and clear out the code nobody uses.
4. Keep building: with a stable base, new features stop breaking old ones, and you can carry on using AI tools where they help.

This is much the same approach as taking over a system whose developer has left: understand and stabilise first, then improve in stages. If you're preparing for investment, it's also the kind of groundwork that makes technical due diligence go more smoothly.

Need a hand?

I build and run my own SaaS products, including My House Move Plan, StoryPrompt and AccessDrop, so I deal with authentication, payments, hosting and backups on live products myself. My fixed-price takeover audit, from £1,500, reviews your app and gives you a written report on what you have, the risks and what to fix first. If you then want help to finish and grow the product, that's what my SaaS and MVP development service is for.

Book a takeover audit