Should You Build From Scratch or Buy a SaaS Boilerplate?

I built and sell Eden Stack, so I obviously have a bias toward buying. But I've also built 7+ apps from scratch, and sometimes that was the right call.

This post isn't a sales pitch. It's the decision framework I wish I had three years ago, when I spent six weeks wiring up auth, payments, and email before writing a single line of product code. Some of those builds taught me more than any boilerplate could. Others were a colossal waste of time.

Let me help you figure out which camp your next project falls into.

The Real Cost of Building From Scratch

Most developers dramatically underestimate how long infrastructure takes. Not because they're bad at estimating, but because they're estimating the happy path. The real cost includes edge cases, security patches, testing, and the inevitable "why is this broken in production?" debugging sessions.

Here's a realistic time breakdown for a production-grade SaaS foundation:

Total: 2-3 weeks before you write any product code. AI tools like Cursor and Claude Code have cut these timelines roughly in half compared to a few years ago, but it's still weeks of integration work rather than product work.

And this estimate assumes things go smoothly. In practice, you'll hit at least a few of these:

• An OAuth provider changes their API and your auth flow breaks
• Stripe webhooks arrive out of order and your subscription state gets corrupted
• Your background job processor silently drops events under load
• A dependency update introduces a breaking change you don't notice until production

Each of these is a 2-8 hour detour. They add up.

When Building From Scratch IS the Right Call

Here's where I break from the "always buy a boilerplate" crowd. There are genuinely good reasons to build from scratch.

You're learning

If you're building your first full-stack app, doing it from scratch is one of the best educational investments you can make. You'll understand auth at a level that no tutorial can teach. You'll know exactly why webhook idempotency matters because you'll debug the consequences of not having it.

A boilerplate abstracts away the lessons. If learning is your primary goal, those lessons are the whole point.

You have specific, unusual requirements

If your app needs to run on-premise, handle HIPAA-compliant data flows, or integrate with a proprietary enterprise system, a general-purpose boilerplate might create more work than it saves. You'll spend time ripping out assumptions that don't match your constraints.

Your team already has institutional knowledge

If your team has built three SaaS products and has battle-tested internal libraries for auth, payments, and email, a boilerplate adds complexity without adding value. You'd be replacing known, trusted code with someone else's opinions.

You want to contribute to open source

Building infrastructure from scratch and open-sourcing the pieces is genuinely valuable work. Libraries like Lucia Auth, Hono, and Drizzle all started because someone decided the existing options weren't good enough. If you're building with the intent to share, the "wasted" time on infrastructure becomes the product itself.

Your project is simple enough

Not everything needs a full SaaS stack. If you're building a blog, a portfolio, or a simple CRUD app, the overhead of understanding and maintaining a boilerplate is worse than just writing the 200 lines of code you actually need.

When Buying Makes Sense

On the other hand, there are situations where building from scratch is actively harmful to your goals.

You have time-to-market pressure

If you're racing to validate an idea, every week spent on infrastructure is a week you're not learning from users. The market doesn't care how elegant your auth implementation is. It cares whether your product solves a real problem.

You're a solo developer

Solo devs face a brutal arithmetic: every hour you spend on infrastructure is an hour you can't spend on product, marketing, sales, or sleep. A boilerplate compresses months of foundational work into days of customization.

You have a validated idea ready to build

This is the sweet spot for boilerplates. You've already validated demand through a landing page, waitlist, or manual process. Now you need to build the real thing, and you need it yesterday. Starting from a production-ready foundation means your v1 ships with proper error tracking, analytics, and payment handling instead of "I'll add that later" (you won't).

You've built this infrastructure before and hated it

If you've already done the educational build and learned the lessons, doing it again is just tedium. There's no new insight in wiring up Stripe webhooks for the fourth time.

The Middle Ground: Free Scaffolds vs. Paid Templates

The choice isn't binary. There's a spectrum between "write everything yourself" and "buy a complete starter kit."

Free Scaffolds

Tools like create-t3-app and Wasp give you a solid starting point at no cost.

Pros:

• Zero financial risk
• Community-maintained
• Opinionated enough to get started, flexible enough to customize

Cons:

• You still wire up payments, email, background jobs, and analytics yourself
• Less integrated; each piece is your responsibility to connect
• Documentation quality varies
• You're on your own for production hardening

Free scaffolds are excellent for the "I know what I'm doing and just want to skip the boilerplate setup" developer. They give you the skeleton but not the muscles.

Paid Templates

Products like Eden Stack, ShipFast, and MakerKit give you a more complete starting point.

Pros:

• Pre-integrated stack (auth + payments + email + jobs + analytics working together)
• Someone else has already debugged the integration edge cases
• Documentation and support
• Regular updates as dependencies evolve

Cons:

• Financial cost (typically $100-300+)
• You inherit someone else's architectural opinions
• Varying quality; some are genuinely excellent, others are glorified tutorials
• Risk of abandonment if the maintainer moves on

The value proposition of a paid template isn't the code itself. It's the hundreds of hours of integration testing, edge case handling, and "why does this break on Safari?" debugging that someone already did for you.

What to Look for in a Boilerplate

If you decide to buy, not all boilerplates are created equal. Here's what separates the good from the mediocre.

Full source ownership

This is non-negotiable. You should get the complete source code, with no hidden packages, no runtime dependencies on the boilerplate author's servers, and no subscription required to keep using the code.

If a boilerplate ships as an npm package you install rather than source code you own, walk away. You need to be able to read, modify, and delete every line.

Active maintenance

Check the commit history. Is the author shipping updates? Are dependencies reasonably current? A boilerplate that was last updated eight months ago is a liability, not an asset. The JavaScript ecosystem moves fast, and security vulnerabilities in outdated dependencies are a real risk.

Documentation quality

Good documentation isn't just "how to install." It's "why this architectural decision was made" and "how to swap out this component for an alternative." You'll inevitably need to modify the boilerplate, and documentation is what makes that possible without reverse-engineering.

AI-friendliness

This is a newer criterion, but it matters more every month. A codebase designed for AI-assisted development has clear naming conventions, consistent patterns, and explicit architecture documentation that AI tools can reference.

In practice, this means:

• Claude skills or similar AI context files that explain the architecture
• Consistent file structure that AI tools can navigate predictably
• Type-safe APIs that give AI tools confidence about what's correct
• Clear separation of concerns so AI can modify one layer without breaking another

A boilerplate that's AI-friendly lets you move faster with tools like Claude Code, Cursor, or Windsurf. One that isn't will have you spending more time explaining context to your AI tools than writing code.

Modern, composable architecture

Beware of boilerplates that are tightly coupled monoliths. You should be able to remove integrations you don't need without the whole thing falling apart. If deleting the Stripe integration breaks the auth flow, the architecture has problems.

The Hidden Cost of "Free"

Here's something the "just use a free scaffold" crowd doesn't talk about enough: free has a cost, and it's measured in time.

When you use a free scaffold or build from scratch, you're signing up for:

• Configuration time: Connecting auth to your database, payments to your backend, email to your job queue. Each integration has its own quirks, environment variables, and edge cases.
• Debugging integration issues: The auth library's session format doesn't match what the payment webhook expects. The email service rate-limits you during testing. The job queue silently drops events when the connection pool is exhausted.
• Keeping up with security updates: Every dependency you install is a dependency you maintain. Auth libraries release security patches. Payment APIs deprecate endpoints. You need to stay on top of all of it.
• No single source of truth: When you assemble your own stack, there's no canonical "this is how these pieces work together" reference. Every developer on the team builds a slightly different mental model.

None of this is impossible to handle. But it's real work, and it compounds over time. The question isn't whether you can do it. The question is whether it's the best use of your limited hours.

The Time Question

There's an insight I keep coming back to: people overestimate what they can accomplish in one year, but severely underestimate what they can accomplish in five years.

The boilerplate question is really about how you spend your limited time.

If you spend six weeks building infrastructure, that's six weeks you didn't spend on product. Multiply that across the three or four ideas you'll try over the next few years, and you've spent nearly six months on plumbing. Some of that time was educational. Some of it was just repetitive.

A boilerplate compresses those six weeks into a few days of setup and customization. That leaves you five extra weeks to build features, talk to users, and figure out if your idea has legs. If it doesn't, you pivot faster. If it does, you scale on a solid foundation.

But here's the thing: if you're early in your career and the learning is the goal, those six weeks of infrastructure work might be the most valuable six weeks of your year. Context matters.

My Framework

Here's the decision tree I'd use:

1. Is this primarily a learning project? Build from scratch. The struggle is the education.
2. Do you have unusual technical constraints? Build from scratch, or heavily customize a boilerplate that's close to what you need.
3. Are you racing to validate an idea? Buy a boilerplate. Every week matters.
4. Are you a solo dev building a real product? Buy a boilerplate. Your time is your most scarce resource.
5. Does your team already have proven internal tooling? Use what you have. A boilerplate would just be noise.
6. Is this your second or third SaaS? Buy a boilerplate. You've already learned the lessons.

There's no universally right answer. But there is a right answer for your specific situation, and it depends on what you're optimizing for: learning, speed, control, or some combination of all three.

Final Thought

The best codebase isn't the one with the most elegant architecture. It's the one that lets you ship a product people want to use. Whether that starts from scratch or from a boilerplate is a detail. What matters is that you're spending your time on the work that only you can do: understanding your users and building something they'll pay for.

Everything else is infrastructure. And infrastructure, one way or another, should be a solved problem.