Most AI-built SaaS apps don't start from a blank file. They start from a starter template — clone, rename, add features, ship. So I ran a local launch-readiness scanner (ai-saas-guard, 65 deterministic rules, no LLM) over 8 of the most popular open-source starters for Next.js + Supabase + Stripe apps — official vendor templates and widely used community boilerplates alike.
196 findings in total. 7 of the 8 templates had at least one critical or high-severity pattern. Here's what kept showing up.
1. The database is wide open in one of the most-copied templates
The only critical findings in the whole run were in one widely cloned Stripe + Supabase template: its starter schema creates broad row-level-security policies (things like "allow all operations for authenticated users") so the demo works out of the box.
That's a reasonable trade-off for a teaching template. The problem is what happens next: an AI assistant scaffolds your app on top of it, you add your tables next to theirs, and the demo policy ships to production unchanged. RLS that lets every signed-in user touch every row is the single most common real-world Supabase incident — and it starts here, as a default.
2. Stripe webhooks that don't finish the job
16 findings across the starters were stripe.webhook.missing-critical-event — webhook handlers that listen for checkout but never handle the events that revoke access (subscription deleted, payment failed). Add missing signature verification and missing idempotency from the wider rule set, and you get the classic launch week story: a user cancels, keeps access forever; or a forged webhook grants a plan nobody paid for.
3. Fake success, ready to ship
19 findings were production code paths containing mock or demo data fallbacks, plus 7 hardcoded fallbacks and more swallowed errors. Starters include demo data so the UI renders before you've wired a database. In production, the same pattern means: the payment provider times out, your API returns a cheerful success with sample data, and nobody finds out until a customer complains.
4. The boring stuff nobody configures
- 33 findings: public environment variable inventories that expose more than intended
- 12: API routes with no rate limiting
- 11: GitHub Actions pinned to floating tags instead of commit SHAs
- 8: routes that check "is this user logged in?" but never "does this resource belong to them?"
None of these are exotic. All of them are one-line-to-one-hour fixes — if somebody looks before launch.
The point isn't that templates are bad
Templates are doing their job: get you running fast. Security hardening is deliberately left as an exercise. The failure mode is new: when an AI writes most of the code on top of the template, there is no human left who remembers which parts were demo trade-offs. The person "reviewing" the PR sees working features, green tests, and no reason to open the migration file from three weeks ago.
That's the gap a launch gate is for. Not a full security audit — a short, deterministic checklist run at the one moment it matters: before the first real users arrive. Scan your starter before you build on it, and scan again before you ship:
npx ai-saas-guard@latest scan --root /path/to/your-saas
Method and limits, honestly
- One scanner (mine), one pass, default rules, on 2026-10-07. Findings are "read this first" signals, not proven vulnerabilities — some are known demo trade-offs, and templates are not production apps.
- Sample: 8 public starters for Next.js + Supabase + Stripe apps, spanning official vendor templates and community boilerplates. Two large production monorepos were scanned separately and are not in these numbers.
- Counts: 5 critical, 43 high, 73 medium, 31 low, 44 info across the 8 repos.
- If you maintain a starter template and want to know whether yours was in the sample and see its detailed list, open an issue — happy to share it privately first.
If you build on a starter, I'd love to hear: did you re-check the template's defaults before launch, or did they ship as-is?
Top comments (1)
Good reminder to read the template before trusting it. Auth and billing defaults are where I'd look first.