Before real users arrive, check eight areas: who can read each piece of data, where your secret keys are, how login and password reset work, how payments are confirmed, what people can upload, what limits stop abuse, whether backups and error tracking exist, and who owns each account. You can check most of them yourself, without code. The database rules and the server code need a second pair of eyes.
AI tools like Lovable, Bolt and Cursor can build a working app in days. They are good at screens and at the main flow. Security is the part that is easiest to miss, because nothing looks wrong in a demo. You are the only user, and you never try to break your own app. This checklist is for founders who are not technical. Each point says what to check, how to check it, and what a good answer looks like. Go through it before you invite people you do not know.
How to use this checklist
Go through the sections in order. The first one is the most serious, because a mistake there can expose every user at once. For each point, write down one of three answers: yes, no, or I do not know. Count "I do not know" as a no.
You need a few things before you start: two test accounts with two different email addresses, two browsers (or one normal window and one private window), a phone, and access to every dashboard your app uses: hosting, database, payments and email.
This list is only about security. For the wider question of whether your app is ready for people, read what must be true before you launch to real users.
Data access and secret keys
In many apps built with AI tools, the code in the browser talks straight to the database. That makes the database rules (the rules that say who may read or change each row of data) the only real lock on your users' data.
- Do the two-account test. Log in as account A and create an item. Copy the address of its page. Open that address while logged in as account B. Then change the number or code in the address by one character and try again. A good answer: B sees an error or nothing at all.
- Every table has rules. If your app uses Supabase, each table needs row level security turned on, with rules that limit each user to their own rows. We explain how to check this in the dashboard, step by step, in is your Supabase database open.
- No secret keys in the browser. Your app uses keys to talk to payment, email and AI services. Some keys are made to be public. Secret keys are not. Ask your builder, or your AI tool, to list every key and where it is stored. A good answer: secret keys live only on the server, in the hosting settings, never in the code that runs in the browser.
- The code is not public by mistake. If your code is stored on GitHub, check that the repository is private. Keys saved in a public repository can be found and copied.
- Admin pages are protected on the server. Hiding the admin button is not protection. Log in as a normal user and type the address of an admin page. A good answer: you are refused.
Login and password reset
Login is the front door of your app. Password reset is the back door, and it gets tested much less.
- A reset link works once and expires. Ask for a reset, use the link, then open the same link again. A good answer: the second try fails.
- The forgot password page does not reveal who has an account. Type an email that has an account, then one that does not. The message should be the same. If it is not, anyone can test which emails belong to your users.
- Email is confirmed before anything important. A new account should not reach private features or send messages to others until the email address is confirmed.
- Log out really logs out. Log out, then press the back button, or open a saved page address. A good answer: the app asks you to log in again.
Payments and file uploads
Money and files are where small mistakes become expensive ones.
- The price is set on the server. If the browser tells the payment service how much to charge, a user can change the amount. Ask where the price is decided. A good answer: in your payment service or on the server.
- Access is given after the payment is confirmed. Reaching the "thank you" page is not proof of payment. The payment service sends a message to your server (called a webhook), and the app should act only on that. Test it: open the success page address directly, without paying. Nothing should unlock.
- Uploads have limits. Accept only the file types you need, for example images and PDF, and set a maximum size.
- Private files stay private. Invoices, contracts and ID documents must not sit in a public folder. Copy the link of an uploaded file and open it in a private window, logged out. A good answer: it does not open.
A demo only has to work for you. A product has to hold up against people you will never meet.
Limits against abuse
Not every visitor is a user. Some are automated programs (bots) that try thousands of passwords, create fake accounts, send spam through your forms, or call your AI feature again and again, on your bill.
- Login attempts are limited. After a few wrong passwords, the app should slow down or pause new tries.
- Forms are protected. Sign-up, contact and invite forms need a limit per address, and often a check that the visitor is a person.
- Paid features have a ceiling. AI answers, text messages and emails cost money each time. Set a limit per user per day. Where the provider offers it, also set a spending limit or an alert.
Backups, errors and logs
- Backups run on their own, and one restore was tested. Know how far back you can go and who knows how to restore.
- Error tracking is on. An error tracking tool records each failure and alerts you. Check that the alerts reach a person who reads them.
- Errors shown to users stay simple. A user should see "something went wrong", not database names or pieces of code. Those details help an attacker.
- Logs do not store secrets. Passwords, card numbers and reset links should never be written into logs.
Who owns the accounts
Good security fails if you cannot get into your own accounts, or if someone who left still can.
- Every account is in your name. Domain, hosting, database, code, payments, email sending and the AI tool itself, all with a company email address you control.
- Two-step login is on. A code from your phone on top of the password, for each of these accounts.
- No shared passwords. Each person who helps you gets their own access, and you remove it when they stop.
- One list of where everything lives. Keep a short note of each service, who has access and where the keys are stored, in a safe place.
What to do with your answers
Start with the data and the keys. If either section has a no, fix it before you invite anyone, even if it delays your launch by a week. The other sections can often be fixed in parallel with a small test group.
This is not a problem with AI tools as such. They build what you ask for, and most prompts ask for features, not for locks. You can ask your AI tool to check each point on this list, and it will often help. But some points, like the database rules and the server code, cannot be seen from the screen. A person who did not write the code finds things the author missed. We explain why these gaps appear in why AI prototypes break with real users.
If you want a quick view of where you stand, our free 2-minute launch check asks simple questions and shows which points are still open. And if several answers are no, see how we finish and secure apps built with AI, starting with an audit of the code and the data.
