What I actually check in your app, and how
If you're about to hand someone your app to "check the security," you should know what that means before you pay for it. So here's the whole method in plain language. If you have questions later, this is the page I'll point you to.
I look at nine things, in the order they tend to go wrong. Some of them anyone can see from the outside. Most of them can't be seen from the outside at all, and those are usually the ones that matter. That gap is the reason a human review exists in the first place.
Why a person, and not just a scanner
Your build tool probably runs a scanner already. Lovable checks your setup on every publish, and Aikido will run an automated pentest for a hundred dollars. Run them. They're a good first pass and I'd never tell you to skip them.
What they can't do is reason about your app. A scanner matches a fixed list of known patterns. It doesn't know that your "share" link exposes another team's data because of the way you happen to model teams, or that two discount codes stack into a free plan, or that an admin flag can be flipped from the browser. Those bugs only exist in the way your particular pieces fit together, and there's no entry for them in a checklist.
The other thing a scanner can't do is stand behind the answer. It prints a report and moves on. If it says "all clear" and you get breached anyway (which happens, even to apps that passed the built-in scan) the tool isn't the one explaining it to your users. That part falls to a person who put their name on the review, fixed what they found, and can show each hole is closed. So treat me as the layer on top of the automated pass, not a swap for it.
Two passes, not one
The free look, from the outside. Before we talk, or on a free 15-minute call, I look at what any visitor can see: your page source, the JavaScript your site ships, your response headers, a few public paths. That catches leaked secrets and basic hygiene, and it tells you whether something looks off. It does not tell you your app is safe, because most of the real risk sits behind the login where an outside look can't reach. I'll say that plainly on the call: the free look tells you there's smoke, not where every fire is.
The full Sweep, from the inside. This is the paid review. I work through the nine areas below against your actual code and database rules, confirm the real ones on my own throwaway accounts, and hand you a written report plus the fixes. Anything active, like actually trying to reach another user's data or testing your login limits, I only do after you've asked me to and handed me the app. Never before.
The nine things I check, most dangerous first
1. Can one user reach another user's data?
This is first because it's the most common serious bug in AI-built apps and the most damaging. The question is simple: if I sign up twice, can account A read, change, or delete account B's stuff? Usually the intended rule is there but doesn't actually hold. Row-level security is switched off, or the rule is written against an empty user id, or a query just forgot the "and only this user's rows" part. You can't see any of this from the outside. It needs the inside pass.
2. Are any secret keys shipped to the browser?
Your app ships JavaScript to every visitor, and sometimes a server-only key rides along in it: a Stripe secret key, an admin database key, an API key. Anyone can open the browser tools and read it. Public keys like a Stripe pk_ or a Supabase anon key are meant to be there, so I won't cry wolf about those. This one is visible from the outside, which is why it's often the first thing I can tell you for free.
3. Does each endpoint check that it's your thing?
An app can correctly check that you're logged in and still never check that the invoice, project, or file you're asking for is actually yours. Change the id in the URL from 1234 to 1235 and you're reading someone else's. The same gap lets a normal user hit an admin-only action when the only thing hiding it was a missing button. This lives behind the login, so it needs the inside pass.
4. Can someone hammer your login?
Most AI-built starters ship with no limit on login attempts, so nothing stops password guessing, email enumeration, or signup spam. I check whether there's a rate limit or a challenge on the sensitive endpoints. I test this gently, a handful of tries, never an actual brute-force.
5. Does the app trust what it's handed?
Whether user input gets checked on the server, whether database queries are written safely, and for anything with an AI feature, whether a user's text can be smuggled into the model or a shell command. The running theme in AI-built apps is that they trust the caller, and a lot of that shows up here.
6. Can the billing be tricked?
Payment logic is full of quiet holes. The price sent from the browser and charged as-is. A "pro" flag the client gets to set for itself. A Stripe webhook that doesn't verify the message really came from Stripe, or one that fulfils the same order ten times because nothing checks for a duplicate. On anything that takes money, this is high-stakes.
7. Can the app be made to call somewhere it shouldn't?
If your app fetches URLs a user supplies, for link previews or webhooks or image imports, it can sometimes be steered into your own internal network or your cloud's metadata service. I check whether outgoing requests are guarded against that.
8. Is sensitive data stored where it shouldn't be?
Tokens and personal data sitting in browser storage, in logs, or in the URL. Session tokens that aren't in a proper protected cookie. Small-looking, occasionally serious.
9. Dependencies and configuration.
Known-vulnerable packages, error pages that spill stack traces, exposed /.env or /.git, source maps, an over-permissive CORS setting, missing security headers. This is the hygiene layer. Most of it is visible from the outside, none of it is dramatic on its own, and all of it is worth tidying.
What you get at the end
A written report in language a founder can act on, not a wall of scanner output. Every finding is rated by how much it actually matters to your app, with the concrete steps to close it. If you'd rather it just be off your plate, I do the fixes myself and show you the proof: the thing that used to leak now returns a clean "denied." You don't have to become a security engineer to ship safely.
The line I won't cross
Before you've asked me to look, I only ever look at what any visitor can see. I don't poke at your live system, I don't touch real user data, and I don't test anything that could break. Active testing happens only after you've handed me the app and asked for it. That boundary protects you as much as me, and I hold it even when a flashier cold email would come from crossing it.
Want the free 15-minute look? Paste your URL and grab a slot: cal.com/roman-sokolov/scan. I'll show you what I can see from the outside, no strings attached.