There's no test that returns "secure". Security isn't a state you reach, it's a set of specific things that are or aren't true about your code, and the useful version of this question is "what's most likely to be wrong right now."
That's answerable, and the answer is narrower than you'd think.
Four things that account for most of it
We built 24 applications across Lovable, Replit and Manus and scanned all of them. 561 vulnerabilities came back. They weren't spread evenly across every possible category. They clustered into a handful of patterns that repeated across nearly every app.
Secrets in the client. Open your deployed site, view source, search the bundle for key, secret and sk_. Anything the app needed to fetch real data may have ended up somewhere the browser can read it.
Endpoints that don't check who's asking. Log in as one user, find a request that fetches your own data, change the ID to another user's and send it again. If their data comes back, that's broken object-level authorisation, and it was the most consequential thing we found.
Auth routes with no throttling. Try logging in wrong twenty times in a row. If nothing stops you, there's no rate limiting on the thing most worth brute-forcing.
Dependencies with known CVEs. Turn on Dependabot or equivalent. This is the cheapest win available and a large share of real breaches trace back to a library nobody updated.
What that tells you and what it doesn't
Those four take under an hour and they'll catch most of what's likely to be wrong with a young application. What they won't do is tell you the app is fine.
Manual checks scale badly. You can test one endpoint for broken authorisation; you can't test eighty. And the checks only cover what you thought to look for, which by definition excludes whatever you didn't know about.
That's the honest limit of doing this by hand.
When to bring in tooling
The line is roughly when you stop being able to hold the app in your head.
Below that, careful manual checks plus dependency scanning is a reasonable position for an early product with few users and no sensitive data. Above it, or the moment you're handling personal data, payments or anything a customer would be upset to see leaked, you want something that runs on every change rather than when you remember.
One thing to know before you buy anything: scanners differ enormously. Not by a few percent. We ran 26 of them across 66 Python repositories with 1,903 vulnerabilities labelled by hand and published the results as RealVuln, and the spread between the best security-specialised system (F3 86.5) and the best rule-based tool (SonarQube, 14.4) is roughly six-fold.
The reason is specific rather than general incompetence. A missing authorisation check has no pattern to match, because correct code and vulnerable code look the same. Where a bug does have a shape, rule-based tools do considerably better, hardcoded secrets being the clearest example.
Worth saying plainly: Kolega is in that benchmark and scores at the top of it, which is exactly the conflict of interest you'd expect. The labels, scanner outputs and scoring code are all public for that reason.
A reasonable order to do this in
Dependencies first, because it's free and automatic. Then the four manual checks above. Then automated scanning in your pipeline once the app is big enough that you can't reason about all of it. A penetration test last, when a customer asks for one, because it's a point-in-time snapshot and expensive to repeat.
The mistake is doing it in reverse. Paying for a pen test on an app that still has API keys in the client bundle.