The 33-point launch checklist tells you what to look for before you launch. But most of it means reading code, and if an AI tool wrote your code, reading it is the hard part.
So I turned the checklist into something your AI tool can run for you. It's an open-source agent skill called launch-readiness-check. It's free, under the MIT license, and it runs entirely in your own tool. Nothing is sent to me.
What a skill is
A skill is a set of written instructions that an AI coding agent like Claude Code or Cursor loads when you ask for a particular job. This one tells the agent how to review an app the way I would: where AI-built apps usually go wrong, what to search for, what is a real problem and what only looks like one, and how to write it up so a non-developer can act on it.
Ask your agent for the check, and it reads your code and writes a report. It doesn't change your code.
What it checks
- Secrets. API keys in code that ships to the browser,
.envfiles in your repository or its history, and AI provider keys called straight from the browser. - Access. Server routes and server actions that don't check who is calling, IDs taken from the request without checking who owns the record (the "user B can see user A's data" bug), and admin checks that happen in the browser.
- Database. Access rules that are missing or let everyone through, write access for logged-out visitors, permissions based on data users can edit themselves, and file storage that is public by accident. It reads Supabase policies, Firebase rules, and the queries in your own server code if you use Prisma, Drizzle or plain SQL.
- Payments. Stripe webhooks that don't verify the signature, paid features unlocked by the browser instead of the server, and subscriptions that never end when a payment fails.
- Costs and abuse. AI endpoints with no login or rate limit, AI calls with no token limit, and uploads with no size or type check on the server.
- Operations. Error tracking, known vulnerabilities in your dependencies, and debug routes left in.
It starts by working out how your app is put together, because that decides where the protection has to be. If your front end talks straight to a hosted database, the database rules are the only real protection. If you have your own server, as most Next.js apps do, every server route has to check the caller itself. The check weights its review to match.
What you get
A file called LAUNCH-READINESS-REPORT.md in your project, with:
- A count of findings by severity, and the three things to do first.
- Each finding explained in one plain sentence ("anyone can read every customer's orders"), then the file and line.
- A confidence level on each: Confirmed, Likely, or Needs review. An automated check should be honest about what it isn't sure of.
- Fix instructions written to paste into your AI tool, and a test to check the fix worked.
- A list of what can't be checked from code: backups, spending caps, email setup and the rest of the dashboard work, as a checklist to tick off.
How to run it
From your app's folder, install it with the skills command-line tool:
npx skills add Farmoi-Oy/launch-readiness-checkOr copy the folder from GitHub into .claude/skills/ (Claude Code) or .cursor/skills/ (Cursor). Then open your project in your agent and ask:
Run the launch-readiness check on this app.Built in a browser tool like Lovable, Bolt, Replit or v0? The check needs your code on your own computer. Connect your project to GitHub from inside the tool, clone it, and open it in Claude Code or Cursor.
If your database rules were set up in a dashboard rather than in your code, the check will say it can't see them and tell you what to check by hand instead.
It's careful by design
- Read-only. The only file it writes is the report.
- Asks before touching anything live. One optional test checks whether your Supabase or Firebase data can be read while logged out, which is what an attacker would try first. It asks your permission, sends read-only requests with the public key every visitor already has, and records only whether data came back, never the data itself. The dependency check also asks first, because it contacts your package registry.
- Masks secrets. A leaked key shows up as its first few characters, so the report is safe to share with whoever helps you fix it.
How to read your report
- Start with Critical and Confirmed. These are the ones that leak data or lose money, and they are real.
- Don't ignore "Likely". It usually means the code looks wrong, but a setting the check can't see might make it fine. Someone has to look.
- Watch how your AI tool fixes things. When it hits an error, the fastest way out is often to loosen a rule until the error goes away. That's how many of these problems got there. Run the test under each fix, every time.
- Treat a short report as a short report. It doesn't mean your app is secure.
What it can't do
It reads your code, so it can't see your database, payment or hosting dashboards, or how the app behaves when someone actually attacks it. It will sometimes flag something that turns out to be fine, and sometimes miss the one route out of forty with a missing check. It's a good first pass, not a penetration test, and not a replacement for an engineer who has seen how these apps fail.
Ran the check?
Then you probably have one of three results: a list you can fix yourself, a list you can't judge, or a list you aren't sure how to fix without breaking something.
The first one is the reason the check is free. Fix it and launch.
For the other two, that's where I come in. I review your results, find what the check can't, and fix it with you. Send me your report: the launch-readiness audit covers the whole app, and a quick check covers the one area that worries you most. Or get in touch and tell me what the report found.
Found a false positive, or a pattern it missed? Open an issue on GitHub. Every report makes the check better for the next founder.