Before you launch your AI-built app: 12 security and stability checks
Built your app with Lovable, Bolt or Cursor and about to let real users in? Go through these 12 checks first, with real cases from a Danish entrepreneur group.
Before real users log in to an app you built with Lovable, Bolt or Cursor, check who can see which data, where your secret keys are, how payments are confirmed, and what happens when something breaks. Below are the 12 checks we go through, most of which you can do yourself in an afternoon.
Why we wrote this
We follow Iværksætter Netværk, a Danish Facebook group for entrepreneurs with more than 130,000 members, and help where we can. In the last few weeks, three posts there stood out:
- A founder had added Stripe payments to an app by describing them to an AI builder. Logged in to Stripe, the founder couldn’t see that anything had been set up, and no order confirmations had arrived. The question to the group: how can I see what I have lost?
- A webshop owner got fake orders paid with stolen American cards. The payment provider said each order cost the shop 22 øre. There were 11 orders and more kept coming, even though the shop only sold to Danish customers. The attackers simply pretended to be Danish.
- A video producer asked for feedback on a new website built with Lovable. We measured it: the homepage downloaded 50 videos, 60.4 MB, the moment it opened. On a mid-range phone, nothing appeared for 3.3 seconds.
None of these owners did anything unusual. The AI tools build what you can see quickly. What they don’t always build is what you can’t see: who may read which data, which messages from Stripe to trust, what happens when a bot finds your checkout.
That is what this list is for.
Who can see what
1. Each user can only see their own data
This is the first thing we check, because you can’t see it on the screen. The app shows each user their own orders or bookings, but the database behind it may hand out everyone’s records to anyone who asks it directly.
You can test the simple version yourself. Create two test accounts. Log in as the first, open one of its records and copy the address from the browser. Log in as the second and paste it. If you see the first user’s record, stop and fix this before anything else.
The more thorough check is in the database. Lovable and Bolt often use Supabase, where access is controlled by Row Level Security. Ask your AI tool to list every table where it is switched off, and to explain in plain words what each table’s rules allow.
2. No secret keys in the browser
Some keys are meant to be public. Supabase’s “anon” key is one of them, as long as check 1 passes. Others must never leave your server: your Stripe secret key, your OpenAI key, Supabase’s “service_role” key.
Anything in the code that runs in the browser can be read by anyone. To look for yourself, open your live app in Chrome, right-click, choose Inspect, go to Sources and search all files for sk_live_ (Stripe secret keys) and sk- (OpenAI keys). If you find one, move it to the server and create a new key. The old one should be treated as public.
3. Admin pages are protected on the server
Hiding the admin menu from normal users is not the same as protecting it. Log in as a normal user and type the address of an admin page straight into the browser. If it opens, anyone who guesses the address can use it. The check that someone is an admin has to happen on the server, for every admin page and every admin action.
4. Login can’t be guessed, and password reset works
One member asked the group whether others also get 7 password-reset emails from WordPress every night. Every one of those emails means someone asked for a reset. Your app will get the same attention once it is public.
Try ten wrong passwords in a row on a test account. Does the app slow you down or block you? Reset a password and check that the link expires and only works once. And decide whether new users must confirm their email address before they get in.
Money
5. Payments are confirmed by the payment provider, not by your app
This is where the Stripe founder above got stuck. When an AI builds a payment flow from a prompt, two things often go wrong.
The first is the price. If the browser sends the price to the payment step, a user can change it. The server should work out the price from its own data.
The second is how an order becomes “paid”. If your app marks an order as paid because the user reached the thank-you page, anyone can open that page without paying. The reliable way is a webhook: a message Stripe sends to your server when a payment has gone through, with a signature your server checks.
Make one real test payment before launch, then look in your Stripe dashboard. You should see the payment there, and the order in your app should change to paid only after Stripe has confirmed it. Also check that the customer gets an order confirmation. In the Stripe case above, it had not been part of the prompt.
6. A bot can’t use your checkout to test stolen cards
The webshop owner’s case looks like card testing. Criminals run stolen card numbers through a real checkout to find out which cards still work, and each attempt can cost the shop a fee. Blocking IP addresses doesn’t stop it, because they switch address with every attempt.
What helps:
- 3-D Secure, so the cardholder must approve the payment in their bank app
- a CAPTCHA on the checkout, since the attempts come from scripts
- a limit on failed payment attempts per session, email address or card
7. A bot or a bug can’t run up your bill
The same goes for anything you pay for per use: AI calls, text messages, emails. A bot that submits your form 10,000 times, or a bug that calls the AI in a loop, is paid for by you. Set a spending limit or at least a usage alert with every provider, and ask your AI tool whether the expensive features have a limit per user.
Data
8. You have backups, and you have restored one
Not every database plan includes backups. Find out whether yours does, how often they run and how far back they go. Then restore one into a separate test project. Until you have done that once, you don’t know whether it works.
9. Personal data is handled under GDPR
If your users are in the EU, their names and email addresses are personal data. Before launch you need:
- a privacy policy that says what you collect and why
- a data processing agreement with each service that stores your users’ data, such as the database, hosting and email provider
- to know where the data is stored
- a way to delete a user’s data when they ask
The simplest way to protect data is not to keep it. When we rebuilt the voice feature in our own app Guidude, we stopped storing voice recordings. The app only needs the text, so the recordings were personal data we had no reason to hold.
Keeping it running
10. You hear about errors before your users tell you
Users who hit an error rarely report it. Break something on purpose in a test version and see whether anyone is told. If nobody is, add an error-monitoring service such as Sentry, and have serious errors send you an email or a message.
11. You can undo a bad change, and your packages are up to date
AI tools change more code than you ask for, so sooner or later a change will break something that worked. Keep the code in version control, for example on GitHub, try changes in a test version first, and know how to put the previous version live again.
While you are on GitHub, switch on Dependabot alerts. Your app is built on open-source packages, and new security holes are found in them all the time. Ask your AI tool to run npm audit and explain any high or critical findings.
12. It works on a real phone, with real amounts of data
Most apps are built on a fast laptop with ten test records. Your users arrive on a phone, over mobile data, with months of records. The video producer’s site looked fine on a desktop. Google’s Lighthouse test measured 0.7 seconds before content appeared on desktop and 3.3 seconds on a simulated mid-range phone, because of the 60.4 MB of video.
Go through your most important flow, such as signing up, buying or booking, on your own phone over mobile data. Then add a few thousand test records and see whether lists and searches are still quick.
The checklist
| # | Check | Done |
|---|---|---|
| 1 | Each user can only see their own data | ☐ |
| 2 | No secret keys in the browser | ☐ |
| 3 | Admin pages are protected on the server | ☐ |
| 4 | Login can’t be guessed, and password reset works | ☐ |
| 5 | Payments are confirmed by the payment provider | ☐ |
| 6 | A bot can’t test stolen cards in your checkout | ☐ |
| 7 | A bot or a bug can’t run up your bill | ☐ |
| 8 | Backups exist, and you have restored one | ☐ |
| 9 | Personal data is handled under GDPR | ☐ |
| 10 | You hear about errors before your users do | ☐ |
| 11 | You can undo a bad change, and packages are up to date | ☐ |
| 12 | It works on a real phone, with real data | ☐ |
If 1, 2, 3 or 5 fail, fix them before anyone outside your team logs in. They decide whether a stranger can read your users’ data or get something without paying. The rest can follow in the first weeks after launch.
Want us to go through it with you?
Some of these checks you can do in an afternoon. Others, like reading database rules or tracing how a payment is confirmed, need someone who reads code.
That is what our System Health Audit is for. The Quick Scan costs 4,995 DKK and is made for small and AI-built apps: we go through security, code, data and scaling, and you get a report with the findings ranked by risk and a fixed price for fixing them. If you continue with us within 60 days, the full fee is deducted from the project.
If there turns out to be more to fix, our AI-built app rescue makes the app safe to grow without starting over.
Book a free 30-minute call and tell us what you have built.
FAQ
Is an app built with Lovable, Bolt or Cursor safe to launch?
It can be. The tools build working apps quickly, but they don’t guarantee that the database is locked down, that secret keys stay on the server or that payments are confirmed by the payment provider. Those things have to be checked before real users and real data arrive.
Which of the 12 checks matter most?
Checks 1, 2, 3 and 5: who can see which data, where the secret keys are, whether admin pages are protected on the server, and how payments are confirmed. If one of those fails, a stranger can read your users’ data or get something without paying.
Can I do these checks without knowing how to code?
Several of them, yes: the two-account test, opening an admin address as a normal user, the wrong-password test, a real test payment, spending limits, restoring a backup and testing on your phone. For database rules, the payment code and the package scan, you need to read code, or ask your AI tool very specific questions and judge its answers.
How long does an audit take?
Our System Health Audits are delivered in 3–10 working days, depending on the package and the size of the app.