A $100 scanner and a person who signs off are not the same purchase
Lovable now runs a security scan every time you publish. Aikido will run an automated pentest against your app for a hundred dollars. Both are real and both are useful, and if you've run them, good. Do that before anything else.
Then read this, because there's a specific line those tools can't cross, and it pays to know where it is before you decide you're covered.
A scanner is a machine checking a fixed list. I don't mean that as a knock. It's the reason it's cheap and instant. But three things sit on the far side of that line, and all three are where AI-built apps actually get breached.
1. A machine checks patterns. It can't reason about your app.
A scanner knows the shapes of known bugs. It doesn't know how your app is put together, and the worst holes in AI-built apps only exist in that wiring.
- Your "share" link exposes another team's data, because of the specific way you modelled teams and invites. There's no pattern for that. It's your data model.
- Two discount codes stack into a free plan, because nothing says they can't. That's business logic, not a signature.
- An
is_adminflag can be flipped from the browser, because one endpoint trusted the request body. A scanner sees a working endpoint and moves on. - Invoice
/1234is yours and/1235is someone else's, and the app never checks. This one, broken access control, is OWASP's number-one web risk and the most common serious bug I find in AI-built apps. Scanners routinely miss it, because the endpoint works. It returns a 200. Nothing looks wrong to a machine.
None of these match a rule. You find them by asking "what happens if I lie here?" and then trying it. That's judgment, and it doesn't come in a checklist.
2. A machine flags. It doesn't fix, and it won't give you a verdict.
A scanner hands you a list of findings ranked by its own generic severity, and stops. You still have to decide what's real, what matters for your app, what to do about each item, and the only question you actually care about: is it safe to launch?
That last part isn't automatable, because it takes someone willing to be wrong or right on the record. I close the holes and prove it, so the request that used to return another user's data now returns a clean "denied." I give you a straight go or no-go on launching instead of a report to decode. And I put my name on that call.
Which is the real gap. A scanner stands behind nothing. If it says "all clear" and you get breached, it isn't the one answering for it. You are. An audit is the opposite arrangement. You're paying for someone who's accountable for the result, and that's what the price difference buys. A machine can't sell you accountability, because a machine can't be held to account.
3. A scan is a snapshot. Your app isn't.
Here's the trap that's specific to how you build. You run the scan, it comes back green, you ship. Next week you prompt Lovable for one more feature, and that prompt quietly reintroduces a hole the scan already passed. The green checkmark is now wrong, and nothing told you.
This is how apps that passed the built-in scan still end up in the news for leaking data. A passing scan is a photo of one moment. Every prompt after it changes something the photo doesn't show. On a fast-moving AI-built app, safety isn't a one-time green light. It's someone looking at each release, which is closer to a standing arrangement than a scan.
So use both, in the right order
None of this is an argument to skip the scanner. It's an argument to know what it is: a fast, cheap first pass that catches the patterned stuff and clears the noise. Run it. Then bring in a person for the three things it can't do, which are reason about your specific app, fix and vouch for the result, and keep looking as you ship.
I'm not competing with the $100 scan. I'm the human layer that sits on top of it and answers for the app once it's live.
Already ran a scanner and want a person to check what it can't? Paste your URL and grab a free 15-minute look: cal.com/roman-sokolov/scan.