DEV Community

Atlas Whoff
Atlas Whoff

Posted on

Why I built an AI SaaS starter kit — and how it saves 40 hours of setup

Most SaaS starters give you the skeleton. You still spend 40 hours wiring the bones together.

Here's what those 40 hours actually look like, and how I eliminated them.

The 40-hour inventory

I tracked every hour I spent on non-product work building my last three SaaS apps before I started using a production-ready starter. Here's what the time went to:

Task Hours
Auth setup (NextAuth + providers + session) 8
Stripe integration (products, prices, webhooks, portal) 10
Database schema + migrations + Prisma setup 5
Middleware (protected routes, redirects, role checks) 4
Email (Resend/Postmark + templates + transactional flows) 5
Dashboard shell (layout, nav, responsive) 4
Deployment config (Vercel + env vars + domains) 3
Error handling + logging 2
Total 41 hours

None of this is product work. All of it is table stakes infrastructure that every SaaS needs. And it's solved — there's a right way to do each of these, and it's not complicated once you've done it a few times.

The problem is that "once you've done it a few times" — the first time is slow, the solutions don't compose cleanly unless they were designed together, and the edge cases (Stripe webhook signature verification, session invalidation on password change, graceful degradation when a payment fails) get skipped under time pressure.


What a real starter should include

I've looked at a lot of starters. Most of them check the boxes but don't actually work out of the box — there's always a missing step, an incompatible version, a feature that's mocked but not implemented. Here's what "production-ready" means to me:

Auth that actually works:

  • Email/password with proper bcrypt hashing
  • Google and GitHub OAuth
  • Magic link as an option
  • Session management with proper expiry and rotation
  • Role-based access (admin vs. user) enforced at middleware level, not just the UI
  • Password reset with time-limited tokens

Stripe that handles the real scenarios:

  • Product and price creation
  • Subscription lifecycle: trial → active → past_due → canceled
  • Webhook handling with idempotency (crucial — Stripe retries)
  • Customer portal for self-serve billing management
  • Usage-based billing option
  • Metered features that degrade gracefully when plan limits hit

Database that scales:

  • Prisma schema with proper relations
  • Migration strategy (not just db push)
  • Connection pooling config for serverless
  • Soft deletes where appropriate
  • Audit log table for billing-critical operations

Dashboard that you can actually ship:

  • Responsive sidebar + topbar layout
  • shadcn/ui components already integrated
  • Dark mode
  • Loading states and error boundaries on every page
  • Table components with pagination, sorting, filtering

The critical pieces most starters miss

1. Webhook idempotency

Stripe will sometimes deliver the same webhook twice. If your handler creates a subscription record on customer.subscription.created, you'll get duplicate records. The fix is a processed_events table with a unique constraint on the Stripe event ID. Most starters don't include this.

2. Plan enforcement that doesn't break UX

When a user hits their plan limit, they should see a clear upgrade prompt — not a 500 error or a silent failure. This requires a layer between your feature code and your plan check that knows how to degrade gracefully. Hard to bolt on later, easy to design in from the start.

3. Trial-to-paid conversion flow

The trial period requires its own state machine: trial_start, trial_active, trial_ending_soon (email at 3 days remaining), trial_ended_active (paid), trial_ended_canceled (churned). Most starters treat trials as a Stripe feature and don't model the product side.

4. Team/organization support

Single-user SaaS is fine to start, but if you'll ever want teams, the data model needs to be right from day 1. Adding a teams table to a user-centric data model later is painful. The starter should have an optional multi-tenant structure that you can ignore until you need it.


My current setup

The AI SaaS Starter Kit I built handles all of the above. It's a Next.js 14 App Router project with:

  • NextAuth v5 — email/password, Google, GitHub, magic links
  • Stripe — subscriptions, one-time payments, usage metering, customer portal
  • Prisma + PostgreSQL — schema with users, teams, subscriptions, audit log
  • shadcn/ui — full component library installed and configured
  • Resend — transactional emails with React Email templates
  • Vercel — deployment config with environment variable documentation
  • Claude API routes — pre-built patterns for streaming responses and tool use

Everything talks to everything else. The auth session knows the subscription status. The middleware enforces plan limits. The webhooks update the database and trigger emails. The dashboard shows real data.

You clone it, add your environment variables (documented in .env.example), and run npm install && npm run dev. No missing pieces.


What 40 hours buys you

I've shipped 3 products in the time it used to take me to set up one. The infrastructure decisions are made and battle-tested. The edge cases are handled. The patterns are consistent across the codebase.

The 40 hours you save isn't just time — it's the 40 hours of frustration, context-switching, and debugging that happens when you're tired of working on setup and just want to ship the thing you actually wanted to build.

Ship the product. Not the scaffolding.


The AI SaaS Starter Kit is a one-time purchase at $99. You get the full source code with no license restrictions — it's yours to modify, extend, and ship as your own product.

Top comments (0)