A few weeks ago someone messaged me about a weekend project. Built with an AI coding tool, real people signing up to try it, no pricing page, no revenue. Their question was simple: is it too early to pay for a security review, or is a free self-check enough for now?
What actually decides this?
Not revenue. What's sitting in your database right now. Money coming in is a business milestone. Real user data landing in a table is a security milestone. Those two things don't happen on the same day, and the second one almost always happens first.
What does a free self-check catch?
There's a real amount of ground you can cover yourself in an afternoon, no budget required. Most of it comes down to one question: can a logged-in user reach something that belongs to someone else?
- Log into two different test accounts and try to pull one account's data while signed in as the other. Change an ID in a URL or API request and see what comes back.
- Open a private route in an incognito window with nobody logged in and see if it still responds.
- Search your repo and your deployed build for API keys, database URLs, or tokens sitting in plain text.
- Ask whoever built your backend, whether that's you or a tool, if row-level permission rules are actually turned on for every table, not just the ones you remember creating.
That last one carries the most weight. The single most common bug in this category traced back to exactly that: a permission rule that was supposed to exist and didn't.
That bug wasn't sitting in toy projects. It was found across apps that already had real users inside them, most with no idea the door was open.
So where does free stop being enough?
The checklist above catches the obvious gaps. It's not a substitute for someone who reviews code for a living looking at yours, and whether the gap matters depends entirely on what you're storing.
If your app holds test data or things nobody would care about seeing, a careful self-check plus fixing what turns up is a reasonable place to stand for now. If it holds a real name paired with an email, phone number, or address tied to an account, you're already holding something worth protecting, customers or not.
If it touches payment details, health information, government ID numbers, anything about kids, or anything a regulator has a name for, that's the point a paid review earns its cost before launch, not after. The incident that actually hurts a company rarely waits politely for the pricing page to go live.
Different shape of bug, same lesson: Base44's authentication flaw let anyone register into someone else's private app using nothing but a public app ID. A security research team reported it privately in July 2025 and it was patched within about a day. Good outcome, but the bug was live and reachable the whole time real users had accounts on it, and it took outside researchers finding it, not the platform's own tooling.
Neither of these happened to some company shipping to millions of people. They happened to apps that looked exactly like the one most people building with AI tools ship on an ordinary Tuesday.
What's the rule of thumb?
Forget the revenue question. Ask two things: what's the worst single record in my database, and who besides me can currently reach it. If the worst record is embarrassing but not dangerous, run the self-check, fix what it turns up, and revisit before you scale. If the worst record could actually hurt a real person, their money, their health, their identity, pay for a proper review before you open signups. Whether anyone's paying you yet doesn't enter into it.
None of the examples above involved a launch party or a big customer win. They involved an app already running quietly, with real people's information inside it, while the builder was still deciding whether this was a side project or a business. That's usually the actual line. Not the first invoice. The first real signup.