"Production-ready."
Every SaaS boilerplate on the market uses that phrase. I spent a week reviewing 11 of them. Here's what I found behind the label.
What "Production-Ready" Usually Means
It means the demo runs. It means there's a Stripe integration that processes a test payment. It means there's auth that returns a JWT. Ship it.
What it doesn't mean... in any of the 11 boilerplates I reviewed:
- Published test coverage numbers. Not one. Zero out of eleven boilerplates tell you how much of the code is tested before you buy it.
- Architecture diagrams. You're supposed to extend this code into a real product. Shouldn't you be able to see how the pieces fit together?
- A security checklist. Auth, webhooks, CORS, SQL injection... there's a baseline of security work that every SaaS needs. Nobody documents what's handled and what's left for you.
The assumption seems to be that if it boots and takes a payment, it's production-ready. That's not production-ready. That's demo-ready.
What I Built Instead
When I built The Unsexy Stack... a FastAPI + Next.js 15 SaaS boilerplate... I made a deliberate choice: treat the documentation and tests as product deliverables, not afterthoughts.
Here's what actually shipped:
111 tests across the full stack.
- 71 backend tests covering auth (JWT validation, JWKS caching, key rotation), webhooks (signature verification, idempotency, race conditions), billing (Stripe subscription lifecycle), CORS, database sessions, and configuration
- 40 frontend tests covering components, middleware, error boundaries, loading states, and page rendering
- Coverage threshold enforced in
pyproject.tomlat 80%... the CI fails if coverage drops below it
17 PDF documents. Not a README with a few paragraphs. Actual documentation you can read offline, hand to a client, or use as a reference while building:
- QuickStart guide
- Architecture overview
- Configuration reference
- Stripe setup walkthrough
- Deployment guide (systemd + nginx)
- Docker guide
- CI/CD pipeline setup
- Security checklist
- Scaling guide (what to add at 100, 1K, 10K, 100K users)
- Customization guides
- Client handoff template
- Troubleshooting reference
- Analytics and monitoring setup
- FAQ
- Changelog
- Philosophy ("Why Unsexy")
- Start Here guide
6 architecture diagrams built with D2... not hand-drawn boxes in Figma:
- System overview (how FastAPI, Next.js, PostgreSQL, Clerk, and Stripe connect)
- Auth flow (JWT validation, JWKS caching, the full request lifecycle)
- Payment flow (Stripe Checkout to webhook to database update)
- Database ERD (full schema and a Starter-tier variant)
- Deployment architecture (nginx, systemd, SSL, the production layout)
A 44-item security checklist split into two parts:
Part 1 covers what's already built into the boilerplate... JWT validation with JWKS caching and asyncio.Lock, RSA key parsing, webhook signature verification, idempotent webhook processing, SQL injection prevention via SQLAlchemy ORM, CORS origin whitelisting, open redirect prevention, rate limiting, security headers, and non-root containers.
Part 2 covers what you need to do before launch... database hardening, Clerk configuration, payment security, infrastructure setup, and monitoring. Each item is marked CRITICAL, HIGH, or RECOMMENDED so you know what to tackle first.
Why This Matters
Here's the practical argument for all of this.
Tests prevent regression. You're going to modify this code. You're going to add models, change the auth flow, customize the billing logic. When you do... the test suite tells you what you broke. Without tests, you're deploying hope.
Documentation prevents ramp-up waste. I've joined projects where the onboarding process was "read the code." On a 50-file codebase that you didn't write... that's days of work that a 10-page architecture doc would eliminate. The diagrams aren't decoration. They're the map you use before touching anything.
The security checklist prevents the breach you don't know is coming. Auth, webhooks, CORS headers... these aren't features you think about until they fail. And when they fail in production with real user data, the cost isn't a bug ticket. It's a breach notification email.
The Real Cost of Skipping This
I'm not trying to shame anyone. Building tests and docs takes real time. Most boilerplate creators are solo developers optimizing for speed... ship the starter kit, get sales, iterate.
But the buyers of these products aren't demo-ing them. They're building real SaaS products on top of them. Products that will handle user data, process payments, and grow into something that needs to be maintained by a team that doesn't include the original developer.
Handing that team a codebase with no tests, no diagrams, and no security documentation isn't saving time. It's transferring risk.
What I'd Check Before Buying Any Boilerplate
If you're evaluating SaaS starters... regardless of stack... here's what I'd ask:
- How many tests are there? If the answer is "none" or "I don't know"... that tells you how much the creator trusts their own code.
- Is there an architecture diagram? If you can't see how the pieces connect before buying, you're buying blind.
- Is there a security baseline? Auth and payment handling have real security implications. What's covered and what's left to you?
- Can you read the code and understand it? Clever code is the enemy of maintainable code. The best boilerplate reads like documentation.
- What happens when you need to change something? Extending the code should feel natural... not like you're fighting the framework.
These aren't unreasonable expectations. They're the bare minimum for something you're building a business on.
The Unsexy Stack is a FastAPI + Next.js 15 SaaS boilerplate with 111 tests, 17 PDF guides, and a 44-item security checklist. It's available at theunsexystack.com.
