TL;DR
Use a boilerplate if you're building a product, not a platform. For 90% of SaaS founders, a boilerplate delivers higher-quality infrastructure faster than building from scratch. The exceptions are real: highly specific technical requirements, existing platform teams, or products where infrastructure is a differentiator. The question isn't "boilerplate or scratch" — it's "which boilerplate, and what will you build on top."
The Honest Comparison
Before the comparison: "building from scratch" is a myth for most developers. You're assembling packages either way. The real question is whether you assemble a pre-assembled collection (boilerplate) or assemble the raw ingredients yourself.
Boilerplate approach:
├── ShipFast ($299)
│ ├── NextAuth (assembled for you)
│ ├── Stripe integration (assembled for you)
│ ├── Email setup (assembled for you)
│ └── Landing page (assembled for you)
└── Your product code on top
"Scratch" approach:
├── NextAuth (you assemble)
├── Stripe SDK (you assemble)
├── Resend SDK (you assemble)
├── Landing page (you build)
└── Your product code on top
The second approach takes 2-4 weeks of your time. That time has a cost.
When Boilerplates Win
1. Speed to First Revenue
For every week you spend on infrastructure instead of product:
- You get feedback later
- You burn runway faster
- Competitors gain ground
A boilerplate compresses auth + billing + email setup from 2-4 weeks to 2-4 days.
2. Handling Edge Cases You Don't Know Exist
Good boilerplates encode hard-won knowledge:
// ShipFast's Stripe webhook handling
// This looks simple. Building it correctly is not.
export async function POST(req: Request) {
const body = await req.text();
const sig = req.headers.get('stripe-signature');
// Verify signature BEFORE parsing JSON — important for security
let event: Stripe.Event;
try {
event = stripe.webhooks.constructEvent(body, sig!, webhookSecret);
} catch (err) {
// Don't expose error details in response — security
return NextResponse.json({ error: 'Invalid signature' }, { status: 400 });
}
// Handle events idempotently — webhooks can be delivered multiple times
const idempotencyKey = event.id;
const existing = await redis.get(`webhook:${idempotencyKey}`);
if (existing) return NextResponse.json({ received: true }); // Already processed
// Process and mark as done
await processStripeEvent(event);
await redis.set(`webhook:${idempotencyKey}`, 'processed', { ex: 86400 });
return NextResponse.json({ received: true });
}
First-time implementation often misses: signature verification, idempotency, proper error handling, failed webhook retries. Boilerplates get this right.
3. Maintained Dependencies
Boilerplates (good ones) update dependencies. When a security vulnerability hits NextAuth or Stripe, Makerkit users get a patch. Scratch builders must monitor and apply patches themselves.
When Building From Scratch Wins
1. You Have a Platform Team
If your company has 5+ engineers dedicated to infrastructure, building internal tooling makes sense. Auth, billing, and observability can be standardized across products.
2. Highly Non-Standard Requirements
Some requirements break boilerplate assumptions:
- Custom auth protocol (SAML federations, custom SSO)
- Non-standard billing (usage-based with complex calculations)
- Unusual deployment (air-gapped environments, sovereign cloud)
- Platform product (your product IS auth or billing for other companies)
3. Infrastructure Is Your Differentiation
If your competitive advantage includes infrastructure (e.g., you're a bank), buying off-the-shelf infrastructure undermines that differentiation.
4. You're an Experienced Team That Hates Other People's Abstractions
Some senior developers genuinely ship faster with their own abstractions. If a team has built 5+ SaaS products from scratch and has reusable patterns, their "scratch" is actually a private boilerplate.
The Real Cost Comparison
Boilerplate route:
| Item | Cost |
|---|---|
| ShipFast purchase | $299 |
| 3 days setup + customization (at $150/hr) | $3,600 |
| Total | ~$3,900 |
Scratch route:
| Item | Cost |
|---|---|
| Auth implementation (5 days) | $6,000 |
| Stripe integration (5 days) | $6,000 |
| Email setup (2 days) | $2,400 |
| Landing page (3 days) | $3,600 |
| Admin panel (5 days) | $6,000 |
| Bug fixes for edge cases (ongoing) | $3,000 |
| Total | ~$27,000 |
These numbers assume a $150/hr developer. Even at $50/hr, scratch costs 5x more.
The hidden cost not shown: Time-to-market. The scratch route takes 20 days. The boilerplate route takes 3 days. At a 6-month runway, those 17 days are 10% of your runway.
What to Customize, What to Keep
The boilerplate dilemma: you'll be tempted to rewrite things that "annoy" you. Resist:
| Keep as-is | Safe to customize | Worth rewriting |
|---|---|---|
| Auth flows | UI components | Almost nothing |
| Stripe webhook handling | Email templates | (Seriously, don't) |
| Session management | Copy and content | |
| Database schema (initial) | Color scheme |
Rewriting auth is how you introduce security bugs. Rewriting Stripe webhook handling is how you lose revenue. Keep the hard parts from the boilerplate and customize the surfaces.
The Honest Recommendation
Use a boilerplate for your first 2 SaaS products. By product 3, you'll have opinions about what you want to change — and the experience to change it safely. Build your own starter at that point.
The best developers I know who "build from scratch" aren't building from zero — they've accumulated a personal starter over years. That's not scratch; that's a private boilerplate.
The "Boilerplate Prison" Concern (Addressed)
The most common argument against boilerplates: "I'll get locked into someone else's patterns and it will be harder to build what I actually need." This concern is real but usually overstated.
The concern makes sense in specific scenarios: you need an unusual auth flow (custom SAML federation, device-based auth), your billing model is non-standard (usage-based with complex calculations), or your deployment requires specialized infrastructure (air-gapped, sovereign cloud).
For the remaining 90% of SaaS products — subscription billing, standard auth flows, conventional deployment — the boilerplate's patterns are exactly what you need. The "prison" concern often comes from developers who associate complexity with differentiation. The boilerplate's auth code isn't your competitive advantage. Your product features are.
The practical test: look at your product's list of differentiating features. If none of them appear in the boilerplate's auth, billing, or email modules, those modules don't need to be custom. Build on the boilerplate, customize the differentiators.
The First 30 Days With a Boilerplate
What actually happens after buying:
Days 1-3: Setup. Configure environment variables, create the database, test Stripe webhooks locally. Follow the boilerplate's documentation. Most boilerplates get you to a running app within 4-8 hours.
Days 4-14: Customization. Remove features you don't need, restyle the landing page and dashboard to match your brand, add your product's unique database tables and API routes. This is where you start diverging from the boilerplate.
Days 15-30: First product features. With infrastructure handled, you're building the actual product — the data models, UI flows, and business logic that define your SaaS.
By day 30, your codebase looks like yours, not the boilerplate's. The auth and billing still work exactly as the boilerplate set them up. The product features you built in weeks 2-3 are what matter.
Signs You Should Build From Scratch
Despite the general recommendation toward boilerplates, there are genuine cases where scratch wins:
- You've built 3+ SaaS products and have a private starter that exactly matches your stack preferences
- Your product IS infrastructure — you're building an auth service, a billing platform, or a database product where the "boilerplate infrastructure" is your core product
- Compliance requires custom everything — some government and financial products have requirements that standard boilerplates can't satisfy
- Your team has 10+ engineers dedicated to platform — at this scale, internal tooling investment has better ROI than external boilerplates
The common thread: scratch is justified when the "standard" approach your product requires is genuinely non-standard.
Key Takeaways
- Building from scratch is assembling the same packages as a boilerplate — just taking 4-6 weeks instead of 3-5 days
- The cost comparison is stark: $299 boilerplate + 3 days of setup (
$3,900 total) vs 20 days of scratch implementation ($27,000 at typical developer rates) - The "boilerplate prison" concern is valid for genuinely non-standard requirements, overstated for standard SaaS patterns
- Use the boilerplate for auth, billing, email, and database setup; build from scratch for your actual product differentiation
- After 2-3 SaaS products, you'll have enough experience to build a private starter that exactly matches your preferences
- The first-time founder case is clearest: ship faster, learn from real users, and customize once you know what matters
What You're Actually Paying For When You Buy a Boilerplate
When a developer buys a $299 boilerplate, they're not just buying working code. They're buying four things: the assembled package choices (auth library, ORM, billing SDK, email provider, component library), the integration code that wires them together correctly, the documentation that explains the opinionated decisions, and — for well-maintained products — the ongoing updates that keep the stack current.
The assembled package choices alone represent significant research time. Choosing between Clerk, Better Auth, and NextAuth.js requires evaluating pricing models, feature sets, ecosystem support, and migration risk. Choosing between Prisma and Drizzle requires understanding edge runtime compatibility, bundle size, and type inference approaches. Most developers don't want to spend a week on these evaluations — they want to trust that a boilerplate author has already done it and made defensible choices.
The integration code is where the real time savings live. A Stripe webhook handler that correctly handles idempotency, signature verification, and all the subscription lifecycle events takes a full day to implement correctly. A Resend-powered email system with template management, unsubscribe handling, and bounce processing takes another day. By buying a boilerplate, you're purchasing dozens of these integration code decisions as a package.
The ongoing updates matter more than they seem at purchase time. Clerk, Supabase, and Next.js have each released breaking changes in the past two years. A boilerplate that received updates for those changes saved its users significant debugging and migration time. A boilerplate that went unmaintained forced users to apply those updates manually without documentation. Evaluating the update history before buying is as important as evaluating the feature list.
For the full range of options — both free and paid — best SaaS boilerplates 2026 provides the curated market view with feature comparisons, pricing, and update history for each option. For teams who want to start with free tools before committing to a paid boilerplate, production SaaS on free tools 2026 covers the zero-cost stack in detail.
Compare the top boilerplates to find the right starting point for your SaaS on StarterPick.
Review ShipFast and compare alternatives on StarterPick.
See our guide to when free boilerplates beat paid for the open source vs paid comparison.