Getting your AI-built app ready for real users
Before real users arrive, check that users can't see each other's data, auth emails actually send, payments are confirmed by webhooks, errors are caught and reported, hosting and database limits won't take you offline, data is backed up, and your privacy notice and cookie setup meet UK rules.
Why it matters
An AI-built app can look finished long before it is ready for strangers. The screens work, the preview works, and you have clicked through it a hundred times. Real users don't follow your path. They sign up with odd emails, open two tabs, close the payment page halfway, share links, and use a three-year-old phone on a train.
The stakes also change at launch. Before, a bug costs you time. After, it can cost a customer their data or their money, and you their trust. Under UK GDPR, a leak of personal data is your problem as the business, not the tool's.
This checklist is what I run before letting real users into an app built with Lovable, Bolt, v0, Replit or Cursor. It is ordered by risk. Do the top sections first. Most items take minutes to check. The ones that fail are the ones worth your time, and they are usually the same few: access rules, auth email, payment confirmation and error handling.
The checklist
Access and data
The single most important check. Most serious problems in AI-built apps are about who can see what.
Access and data
- Create two test users. Log in as one and try to open the other's records by changing IDs in the URL or the network request.
- Every table holding user data has row level security switched on, with policies that limit rows to their owner. Supabase's own guidance is to enable it on every table in an exposed schema.
- No policy only checks whether someone is logged in. Being signed in is not the same as owning the row.
- Admin pages are blocked on the server or in the database, not just hidden in the menu.
- Lovable: run the Deep scan from the Security view and read every finding. The Quick scan on publish does not review your app's own logic.
- Bolt: run the Security Audit, then test by hand, because it covers the database only.
- Uploaded files are private unless they are meant to be public, and file URLs can't be guessed.
Secrets and server code
AI tools have got much better at keeping keys out of the browser. Lovable spots keys pasted into chat and points you to its Secrets store, and Bolt's database settings have a Secrets section for the keys your project uses. The risk is what happened before those habits kicked in, and server functions that hold a key safely but will do expensive work for anyone who calls them.
Secrets and server code
- No secret key appears in front-end code, in the repository, or in chat history. Search the code for sk_, rk_ and service_role.
- Every key that was ever pasted somewhere public has been rotated.
- Every server or edge function checks who is calling before it reads data, sends email or calls a paid API.
- Functions that cost money per call, such as AI requests, have a per-user limit.
Sign-up, login and email
Login is where the preview and the live site differ most. Redirects, email links and social sign-in all depend on the domain, so something that worked in the editor can fail on your real address. Email is the other trap: the default sender on most backends is fine for testing and nowhere near enough for a launch.
Sign-up, login and email
- Sign-up, email confirmation, password reset and social login all work on the live domain, not just the preview.
- The live domain is in your auth provider's allowed redirect URLs.
- Auth emails go through your own SMTP provider. Supabase's default allows 2 emails per hour.
- Sender domain has SPF and DKIM set up, so emails don't land in spam.
- CAPTCHA is on for sign-up, sign-in and password reset if bots are likely to find you.
- Deleting an account actually deletes or anonymises the user's data.
Payments
If you charge money, this section decides whether your records match what people paid. The rule is simple: Stripe tells your server, your server grants access. The browser only shows progress.
Payments
- Paid access is granted by a verified Stripe webhook, not by the success page loading.
- Pay with test card 4242 4242 4242 4242, close the tab before the success page loads, and the account still upgrades.
- Cancellations, failed renewals and refunds remove access correctly.
- Live products, prices and webhook endpoints exist. Sandbox ones don't carry over to live mode.
- One real low-value purchase on the live site, refunded afterwards.
The detail is in adding Stripe to an AI-built app properly.
Errors and monitoring
AI-generated code tends to handle the happy path well and the failure path barely at all. You want two things: users who hit an error see a message they understand, and you hear about it before they email you.
Errors and monitoring
- Every form shows a useful message when something fails. No blank screens, no endless spinners.
- Front-end and server errors are reported somewhere you will see them, with an alert by email or chat.
- You know where the logs are for each part: hosting, database, edge functions, Stripe.
- A simple uptime check pings the live site and tells you when it is down.
Limits, performance and mobile
Free plans are generous for building and tight for launching. A post that does well on social media can push a free-plan app over its limit within hours, which is the worst possible time to go offline.
Limits, performance and mobile
- You know your hosting plan's limits. Bolt's Free plan allows 10 GB bandwidth and 333,333 requests a month, then the site stays offline until the next billing cycle.
- Lovable Free plan: newer apps are capped at 1,000 server requests per project every 10 seconds before visitors see a temporary unavailable page.
- Your database won't pause. Supabase Free projects with low activity over 7 days may be paused, and Bolt may pause databases in unpublished projects after six or more days of low use.
- The slowest page loads in a few seconds on a phone over mobile data.
- Lists that grow are paginated, and the columns you filter on are indexed.
- The full journey works on a small phone screen, including sign-up and payment.
Backups and recovery
Backups matter most the first time someone deletes something they shouldn't, which is often you, running a script against the wrong database.
Backups and recovery
- Backups are on, and you know how far back they go. Supabase Free plan backups can't be downloaded.
- You have restored a backup once, to a separate project, and checked it.
- Code is synced to a GitHub repository the business owns.
- Stored files are backed up or can be recovered separately from the database.
Privacy and UK rules
You are the business collecting personal data, so this part is on you, whichever tool built the app. None of it is legal advice. It is the minimum I would expect to see before a UK launch.
Privacy and UK rules
- A privacy notice says what you collect, why, which services process it, and how people can ask for their data or deletion.
- Non-essential cookies and trackers wait for consent, with reject as easy as accept, unless an exception applies.
- Analytics fits the ICO's statistical purposes exception, or sits behind consent.
- Terms of service cover payments, refunds and acceptable use.
- You have a record of the third parties that process personal data for you: hosting, database, email, payments, analytics.
For the cookie and analytics side, see analytics and tracking set up right. For the wider data protection picture, see GDPR for UK startups.
Support and operations
Your first users will find problems you never imagined. What matters is how quickly you hear about them and how safely you can ship a fix.
Support and operations
- Users can contact you from inside the app, and someone reads that inbox daily.
- There is a way to make changes without editing the live app directly: a staging copy or preview deployments.
- Analytics can answer the one question this launch exists to answer.
- You can tell who your first users are and talk to them.
Common misses
These are the items I see skipped most often, usually because the app seemed to work.
Testing access with one account. Everything looks right when you are the only user. Data leaks only show up when a second account tries to see the first account's records. It takes ten minutes to test and it is the check I would never skip.
Trusting the scan. The built-in scans are good and worth running. They are also honest about their limits. Lovable's docs say its tools cannot guarantee complete security and recommend a professional review for apps handling sensitive data. Bolt's audit covers the database only.
Auth email limits. Launch day goes well, then sign-ups stall because confirmation emails stop after two an hour. Custom SMTP takes half an hour to set up and fixes it.
Preview versus live. Lovable publishes a snapshot, so edits don't reach the live site until you publish again. Bolt runs its development environment in your browser on WebContainers, which is not the server your users will hit. Test the live domain, not the editor.
Upgrading on the success page. It works in every test you run, because you never close the tab early. Real customers do.
Free-plan limits. A launch that goes well can take a free-plan app offline. Check the limits before you post anywhere with a large audience, and upgrade the week before, not the hour after.
Secrets in the history. A key removed from the code is still in the Git history and in old chat messages. Removing it is not enough. Rotate it.
Testing on desktop only. Most first visits from social media or email happen on a phone. A sign-up form that hides its button behind the keyboard loses those users silently.
No way back. If you have never restored a backup, you don't have one. You have a hope.
Next step
Work through the sections in order and fix as you go. Access and data first, then payments, then the rest. If an item fails, fix it before moving to cosmetic work. A slightly rough interface that keeps data safe is a better launch than a polished one that doesn't.
If you are not sure whether you have a prototype or an MVP yet, prototype vs MVP vs product will help you decide what is worth fixing now. The full path from prototype to launch is in the prototype to product guide, and there are tool-specific versions for Lovable and Bolt.
If you would rather hand this over, it is what my Rescue Sprint covers, and the free vibe-code health check gives you a first read in a few minutes.
- Lovable docs: Security, checked 10 November 2026
- Lovable docs: Hosting, checked 10 November 2026
- Bolt docs: Intro to Bolt, checked 10 November 2026
- Bolt docs: Database, checked 10 November 2026
- Bolt docs: Hosting plans, checked 10 November 2026
- Supabase docs: Production checklist, checked 10 November 2026
- Supabase docs: Row level security, checked 10 November 2026
- Stripe docs: Go-live checklist, checked 10 November 2026
- ICO: What are the exceptions? (storage and access technologies), checked 10 November 2026
The launch checklist for founders, as a PDF
About 40 checks across legal, payments, domain and email, analytics, backups and support.
Questions founders ask
Is the Lovable or Bolt security scan enough before launch?
No. Lovable says its scans cannot guarantee complete security, and its Deep scan only runs when you ask. Bolt's Security Audit covers the database only. Use them, then test access by hand with two accounts.
Why are sign-up emails not arriving after launch?
If your app uses Supabase's built-in email, it allows only 2 auth emails per hour. Set up your own SMTP provider before launch so confirmation and reset emails keep flowing.
Can a free plan take my app offline?
Yes. Bolt's Free hosting plan stops serving sites that hit their monthly limit until the next billing cycle, and Lovable's Free plan caps newer apps at 1,000 server requests per project every 10 seconds.
How long does it take to get an AI-built app launch-ready?
It depends on what the checklist turns up. If access rules and payments are sound, it can be a few days of fixes. If they are not, fix those first, before anything cosmetic.
Ant
Product designer who builds MVPs, based in Nottingham. 10+ years designing digital products, and the only person at BlackFig. More about me