▸ CLAUDE CODE SKILL · MIT · STACK-AGNOSTIC

PRODUCTIONHAS A BOUNCER.

You shipped an app with Lovable, Bolt, v0, or Claude Code. It works on your screen.launchworthy audits the five domains between "works for me" and"real users are paying and nothing is on fire" — then hands you a scored punch list to get in.

install · ~10 min, once
Star on GitHub
CURRENT VERDICT ON A TYPICAL AI-BUILT APP0/5 · ACCESS DENIED↓ SCROLL TO RUN THE AUDIT

01 · THE GAP

It works on your screen. That is the most expensive sentence in software — because "works for me" and"real users are paying for this and nothing is on fire"are two completely different apps, and the distance between them is where you get breached.

  • -RLS turned off on your tables
  • -service_role key shipped in the browser bundle
  • -no rate limit on a paid AI endpoint
  • -no error tracking, no backups, no rollback

You will not find these. A stranger will. launchworthy finds them first.

02 · THE SCORECARD

Do-not-launch safe-to-launch, in one scroll.

launchworthy · taskflow — Vite + React + Supabase · Vercel · pre-launch
#DOMAINVERDICTFINDINGS
1Frontend & ExperienceWARNPASS1 high, 2 med, 1 lowclean
2Backend & DataWARNPASS1 high, 1 medclean
3Auth & SecurityFAILPASS2 crit, 2 highclean
4Infrastructure & DeployWARNPASS1 high, 1 medclean
5Operations & RecoveryFAILPASS3 high, 1 medclean
Overall: 0/5 domains green · 2 crit, 8 high, 5 med, 1 lowOverall: 5/5 domains green · launchworthy

03 · THE FIVE DOMAINS

Five domains
between you and
real users.

Each one is a question the audit answers against your actual code — worst-first, with exact file paths.

DRAG / SCROLL →
1DOMAIN 1 / 5

Frontend & Experience

What do users see when things go right, and when they break?

WHAT IT CATCHES

  • -White screens on error
  • -Missing loading & empty states
  • -Broken responsive layouts
  • -Accessibility gaps
2DOMAIN 2 / 5

Backend & Data

Does the engine hold up: APIs, database, jobs, and data flow?

WHAT IT CATCHES

  • -DB or admin keys reachable from the browser
  • -No input validation
  • -No connection pooling · N+1 queries
  • -Unguarded calls to paid AI
3DOMAIN 3 / 5

Auth & Security

Are the wrong people kept out, and are the bills safe from abuse?

WHAT IT CATCHES

  • -Supabase RLS off · open Firebase rules
  • -User A can read user B’s data
  • -Secrets shipped in the bundle
  • -No rate limit on your paid AI endpoint
4DOMAIN 4 / 5

Infrastructure & Deployment

Can you ship, roll back, and serve it fast and safely?

WHAT IT CATCHES

  • -One environment, no staging
  • -No rollback path
  • -No health check · no CI
  • -No CDN
5DOMAIN 5 / 5

Operations & Recovery

Will you know when it breaks, and can you survive it?

WHAT IT CATCHES

  • -No error tracking
  • -No backups
  • -Untested restores
  • -Can you rebuild in under an hour?

3 pass, 2 fail?

You are not launchworthy until all five are green.

Run the audit →

04 · HOW IT WORKS

Three steps. Ten minutes. Then re-run forever.

  1. 01Install once

    A one-time setup inside Claude Code. The plugin is then available in every project you ever open.

  2. 02Ask in plain English

    No flags to memorize. Just say what you want. launchworthy detects your framework and backend and adapts every check to your stack.

    Is this app production ready? Harden it.
    Will this survive real users? Audit it.
    Is my Supabase secure?
  3. 03Fix, then watch it climb

    You get a scored report in tmp/. It offers to apply the safe fixes — only with your confirmation, only on a clean git state. Fix the blockers, ask again, watch the score go 0/5 5/5.

05 · WHY IT'S CREDIBLE

It flags the real bug — not the fake one.

A generic checklist screams about every key in your bundle. Half the time it's wrong. The anon key in your Supabase frontend is supposed to be there. Theservice_role key next to it is a full-database master key that bypasses every rule you wrote. launchworthy knows the difference — because flagging the anon key is how a security report tells you it's amateur.

audit · lib/supabase.ts
IGNORED
anon key in the client bundle— public by design; RLS is the real gate
[CRITICAL]
service_role key in the client bundle— bypasses RLS entirely · rotate it now
[CRITICAL]
RLS disabled on tasks, profiles— anyone with the anon key reads every row

Getting this pair right is the whole game.

06 · IT ARGUES BACK

The excuses that feel most reasonable
are the ones that get people breached.

Every objection has a counter loaded. It tells you the truth about the risk — then lets you decide.

YOU: "It’s just an MVP."

launchworthy: An MVP with real signups is a real product to the person whose data is in it. The RLS-off table does not know it is an MVP. Attackers scan for it the same day you deploy.

YOU: "I’ll add auth later."

launchworthy: "Later" means after the first user, or the first breach. Turning on RLS after you have live data is harder, not easier. The cheapest time is now, before there is data to leak.

YOU: "No one will find it."

launchworthy: Bots find it. Exposed Supabase projects and open Firebase databases are indexed and scanned continuously. "Nobody knows my URL" is not a security control.

YOU: "The AI tool wouldn’t ship it insecure."

launchworthy: AI coding tools optimize for a working demo, not a hardened deploy. They leave RLS off, secrets in the client, and no rate limits by default. That gap is the entire reason this exists.

0

domains audited

frontend → ops

0

copy-paste fix playbooks

RLS, rate-limits, headers…

0 min

to install, once

then every project

$0

MIT-licensed, forever

fork it, ship it

▸ THE BOUNCER IS FREE. THE BREACH IS NOT.

Is your app
launchworthy yet?

Star on GitHub

Then just ask Claude: "Is this app production ready? Harden it."