Indie launches fail in boring, avoidable ways: a leaked key, an open API route, a webhook that double-charges, a layout that breaks on mobile, a missing privacy page. None of these require a security team to fix — they require going through the app deliberately before strangers do. Use this as a pre-flight checklist.

A launch-readiness review scores security, reliability and SEO basicsServer-side auth & authorizationPassSupabase RLS & tenant isolationPassSecrets kept out of the clientPass!Rate limits on costly endpointsReviewVerified, idempotent webhooksPass!robots.txt, sitemap, canonicalReview
A launch-readiness review scores security, reliability and SEO basics so blockers surface first.

Identity and access

Most exploitable bugs live here. Get authentication and authorization onto the server and the rest gets much easier.

  • Authentication: every sensitive route verifies the session server-side, not just the UI.
  • Authorization: role and ownership checks run on the server; never trust a role or ID from the client.
  • Admin routes: /admin and internal tools are gated by a real server-side role check.
  • Test accounts: seeded demo users, default passwords, and impersonation/debug endpoints are removed before launch.

Data and database

If you use Supabase or any client-reachable database, this section is where tenant data leaks happen.

  • Supabase RLS: enabled on every user/tenant table, with policies scoped to auth.uid() or workspace membership.
  • Database permissions: no USING (true) policies; INSERT/UPDATE policies include WITH CHECK.
  • Tenant isolation: a second test account cannot read or write the first account's rows.
  • File uploads: user buckets are private, served via signed URLs, with type and size validated on upload.

Run all of these checks automatically and get a prioritized report.

See the launch readiness checklist

Secrets and configuration

  • Environment variables: secret keys live server-side only; public/VITE_/NEXT_PUBLIC_ variables contain nothing privileged.
  • Public vs private keys: publishable keys and anon keys are fine to expose; service-role and secret keys are not.
  • Git history: no live secrets ever committed; rotate anything that was.
  • Deploy config: required variables are actually set in production so auth and billing don't silently fail.

API routes and abuse prevention

  • API route exposure: ID-based routes (/api/x/[id]) are scoped by owner to prevent IDOR.
  • Rate limiting: per-IP and per-account limits on auth, signup, upload, and AI-backed endpoints, with hard usage caps.
  • Form validation: request bodies validated against a schema at the API boundary, unexpected fields rejected.
  • CORS: no wildcard origins paired with credentials.

Payments and webhooks

If money moves, this section is load-bearing. Most billing bugs come from trusting the client or the unverified webhook body.

  1. Verify the provider signature against the raw request body before processing a webhook.
  2. Derive the plan, price, and quantity from the provider — never from request data.
  3. Make webhook handlers idempotent so retries and replays can't double-grant or double-charge.

Reliability and observability

  • Error handling: failures return generic messages to users; no stack traces or SQL errors in responses.
  • Error states: every data view has loading, empty, and error states — no blank screens on failure.
  • Logging: no passwords, tokens, or full bodies in logs; personal data scrubbed from your error tracker.
  • Broken links: internal links, buttons, and routes are crawled and fixed before launch.

Discoverability and technical SEO

You want both search engines and AI assistants to understand the product. Give them clean, crawlable structure.

  • robots.txt allows crawling and points to your sitemap.
  • sitemap.xml lists your real public pages.
  • Each page has a unique title, description, and canonical URL, plus OpenGraph tags.
  • Semantic HTML with exactly one H1 per page and a sensible H2/H3 structure.

Privacy, analytics and the human layer

  • Mobile responsiveness: core flows tested on a real phone viewport.
  • Analytics/privacy: a privacy page, honest cookie/consent handling, and GDPR basics for the data you collect.
  • Security contact: a way for someone to report an issue responsibly.
  • Backups and a recovery plan: you know how to restore data if something goes wrong.

This is a long list, but it's finite and mostly mechanical. The fastest way through it is to automate the repeatable parts — secrets, RLS, IDOR, rate limits, webhook verification, technical-SEO basics — and reserve your attention for the judgment calls about your specific product.

Get a founder-readable pre-launch report that flags blockers first.

Scan your repo for free