10 things to check in your AI-built app before you take payments.
If you built something with Lovable, Bolt, Replit, Cursor or Claude Code and people are starting to use it, these are the ten things most likely to be wrong. Each one is something you can check yourself, today, without a developer. Under each is what it means if you find it, and what it costs you if you don’t.
Work down the list in order — it’s roughly ordered by how badly the first item will hurt you. Write down what you find. If you get through it and three or more are true, you have a real problem, and it is a fixable one. If none are true, you’re in better shape than most and you can stop reading.
Ten checks, in order of how much they cost you.
Are your API keys visible in the browser?
How to check: open your live site, right-click, choose “View page source”, then search the page (Ctrl-F or Cmd-F) for sk_, key, secret and api. Do the same on the network tab of your browser’s developer tools. Look for anything resembling your Stripe, OpenAI, SendGrid or database keys.
What it means: anything shipped to the browser is public, permanently, to everyone. There is no such thing as a hidden value in front-end code.
What it costs you: someone else spends your OpenAI budget, sends email as you, or reads your database directly. Rotate the key first, then move the call to a server.
Can one user read another user’s data?
How to check: create two ordinary accounts. Log in as the first, and find a URL containing an id — an order, a profile, a document. Log in as the second in a private window, and paste that same URL in. If you can see the first user’s data, you have found it. If you use Supabase or Firebase, also open the console and confirm row-level security or security rules are actually switched on.
What it means: these platforms start permissive so your app works on day one. Tightening them is a step people don’t know exists.
What it costs you: this is the single most common serious finding, and depending on where your users live it is a reportable data breach rather than a bug.
Does your app check permissions on the server, or only hide the button?
How to check: find something only an admin should do. In developer tools, look at the network request the admin action sends. Then, logged in as an ordinary user, send that same request — or simply visit the admin URL directly. If it works, the check was cosmetic.
What it means: hiding a control in the interface is not the same as refusing the action behind it. The API is a door; the UI is a sign on the door.
What it costs you: any user can do anything an admin can, and nothing in your logs will look unusual.
Do you verify that payment webhooks really came from your payment provider?
How to check: find the code that handles your Stripe, Paddle or PayPal webhook. Search it for signature, verify or constructEvent. If there is no signature check, it accepts whatever is posted to that URL.
What it means: your provider signs every message so you can prove it came from them. Skipping the check means trusting a stranger’s word about whether they paid you.
What it costs you: free subscriptions, unlimited credits, refunds you never issued — granted by your own app, to anyone who finds the URL.
Is there any limit on how often someone can hit your endpoints?
How to check: try your login form with the wrong password twenty times in a row. If it lets you keep going with no delay, no lockout and no captcha, there is no rate limiting. Check the same for signup, password reset, and anything that calls an AI model.
What it means: your app will do as much work as anyone asks it to, as fast as they can ask.
What it costs you: passwords brute-forced overnight, a five-figure AI bill from one script, or an outage caused by a single bored person.
Are there secrets in your git history?
How to check: in your repository, run git log -p | grep -iE "api[_-]?key|secret|password|sk_live". Deleting a key from a file does not remove it from history — you have to look at the history itself. If the repository is or ever was public, assume the key is already known.
What it means: git keeps everything. Every clone carries the whole history with it.
What it costs you: automated scanners find keys in public repositories within minutes of a push. Rotating the key is the fix; deleting the line is not.
Have you ever restored a backup?
How to check: not “do backups exist” — have you taken one and actually restored it into a separate environment, and confirmed the data was all there? If the honest answer is no, you have never tested your backups.
What it means: an untested backup is a belief about a file, not a recovery plan.
What it costs you: the morning you need it is the worst possible time to discover it has been silently failing since March.
Do you find out about errors before your users tell you?
How to check: is there anything — Sentry, a logging service, an alert of any kind — that emails or messages a human when your app throws an error in production? If your answer is “I check the logs sometimes”, the answer is no.
What it means: without error reporting, every failure is invisible unless someone bothers to complain.
What it costs you: most users don’t complain, they leave. You are probably losing signups right now to a bug on a device you don’t own.
Can you deploy without risking the live site?
How to check: is there a staging environment where changes go first? And if a deploy goes wrong, do you have a tested way to get back to the previous version in minutes — one you have actually used?
What it means: deploying straight to production means your customers are your test suite.
What it costs you: one bad Friday deploy and an outage that lasts as long as it takes you to work out what changed.
Is anything at all tested?
How to check: look for a test folder, or a command like npm test. Then ask the real question: if you changed your signup flow tomorrow, what would tell you that payments had stopped working? If the answer is “a customer”, you have no safety net.
What it means: full test coverage is the wrong goal, and chasing it wastes money. Tests around payments, login and anything that touches user data are not optional.
What it costs you: every change becomes a gamble, so eventually you stop changing things — which is a slower, quieter kind of failure.
Reading the result.
- Nothing found. Genuinely good, and rarer than you’d think. You don’t need to hire anyone. Come back to this when traffic or the amount of money moving through it changes materially.
- One or two found. These are usually a day or two of work and often something you or your AI tool can fix now that you know to ask. Fix the key exposure and the database rules first — they’re the ones that don’t get better on their own.
- Three or more found. The pattern matters more than the count. Several of these together usually means nobody has looked at the whole system, and the items you can’t check from this list are the ones worth worrying about.
- You couldn’t check most of them. That’s the honest and most common answer, and it isn’t a failing — not knowing what you don’t know is the entire problem with building this way.
No email gate, no download form, nothing to sign up for. If it’s useful, send it to whoever else is building this way — that’s the whole point of it existing.
The paid version of this is $500.
A technical review covers everything above plus the things you can’t check from the outside: how your data is actually modelled, what happens under load, where the costs are going, and which of the findings genuinely matter for your situation as opposed to being noise. You get a written report, a risk list ordered by consequence, a remediation plan with real numbers, and a call to walk through it.
If it only turns up a couple of small problems, I’ll fix them as part of the $500 rather than quoting you for an engagement you don’t need. Plenty of people take the report and stop there.
And if nothing on this list was true of your app, don’t book anything. There’s nothing here for me to sell you yet.
Found something and not sure how bad it is?
Twenty minutes. Tell me what you found and I'll tell you honestly whether it needs paying for. If the answer is no, that's what you'll hear.