I ran 290 pre-launch checks against 68 open-source codebases: Django, Rails, Sentry, GitLab, Supabase, cal.com, Ghost, Directus, FastAPI, Express and 58 others. Not AI-generated side projects — mature software with paid maintainers, code review and years of production traffic.
They produced 1,943 findings. After removing one check my own audit flagged as unreliable (more on that below), 1,616.
What almost everyone gets wrong
86 of the 290 checks fired at all. Twenty-two fired in ten or more of the 68 projects — those are the ones worth your attention, because a problem that appears in a third of well-maintained codebases is not an accident, it is a thing the ecosystem forgets.
| What | Repos |
|---|---|
| No social preview image on shared links | 24 / 68 |
| No health endpoint for the deploy to check | 20 / 68 |
| Migrations with no way back | 19 / 68 |
SELECT * on wide or hot tables | 16 / 68 |
| Dependencies with published advisories | 16 / 68 |
| HTTPS not enforced | 15 / 68 |
| Security headers missing | 15 / 68 |
| No terms of service | 15 / 68 |
| No timeout on outbound calls | 14 / 68 |
| No rate limiting on any endpoint | 14 / 68 |
The pattern in that list
Look at what is not there. No SQL injection, no leaked keys, no authentication bypass. The famous vulnerabilities are largely absent from mature projects, because those are the ones people look for.
What is there is the unglamorous half: a migration nobody can undo at 2am, a query that is instant with fifty rows and a timeout with fifty thousand, an outbound call with no timeout that holds a request open until the server runs out of them. None of these are vulnerabilities. All of them are how a launch goes wrong.
The most common finding of all was a missing social preview image — in a third of these projects, a shared link renders as a grey box. That is not a security problem. It is a thing nobody owns, which is exactly why it survives in software this well maintained.
204 checks found nothing
Two thirds of the checks did not fire once. That is the result I care about most, and it is the reason the run is worth reporting at all.
A scanner that flags something in every file is not finding problems, it is producing noise, and the reader learns to scroll past it. Twenty-four checks fired in exactly one repository out of 68 — each of those is either a genuinely rare mistake or a rule that needs tightening, and knowing which is the work.
The one I threw out
One check produced 327 findings across 16 repositories — a fifth of
everything, from a single rule. My audit marks that automatically as
SUSPICIOUS — far too many, because a real problem is not
that common in software this reviewed.
It was the accessibility baseline check, and it is matching too broadly. It is excluded from every number above, and it is on the list to fix rather than in a table pretending to be a discovery. Publishing it as a finding would have been the single most impressive number in this article, and it would have been wrong.
What to do with this
If you are about to launch something, the ten rows above are a better starting list than anything sorted by severity, because they are sorted by how often real teams miss them. Start with the migration rollback and the outbound timeout: both are cheap, both are invisible until the worst possible moment.
The longer version, organised by the order things tend to hurt, is the pre-launch checklist. A complete unedited scan of one codebase, so you can judge the output rather than my summary of it, is here.
And the 290 checks run on your own machine, free and unlimited:
npx launchprep