SaaS boilerplate vs building from scratch: the math

The boilerplate-versus-scratch debate usually gets argued as ideology when it is actually arithmetic. Your product shape, your calendar, and your willingness to read someone else’s code decide the answer — and both paths are defensible once you run the numbers honestly.

Should I use a SaaS boilerplate or build from scratch?

Use a boilerplate if you are a solo founder or small team shipping a conventional subscription product against a deadline; build from scratch when infrastructure itself is your product, when the project exists to teach you infrastructure, or when your requirements are genuinely unusual. For everyone in the middle, the kit wins — provided you treat it as code you now own, not code you outsource.

Three inputs decide it. Product shape: if your roadmap is accounts, plans, dashboards, and one distinctive workflow, that is exactly the surface boilerplates cover; if your core innovation is a novel data model, real-time engine, or unusual compliance boundary, expect to fight the kit’s assumptions and budget for the fight. Timeline: the empty-repo path costs months that a validation window may not have, and the honest schedule ranges are in how long to build a SaaS. Understanding: buying a kit does not remove you from the code — plan two to five days in week one to read its conventions, trace an authenticated request end to end, and locate where sessions are stored and webhooks are verified. If you cannot answer those two questions after reading the docs, either schedule more reading time or build it yourself; shipping a foundation you have never read is how 3am incidents happen.

There is also a middle path worth naming: start from a kit and replace parts as your requirements diverge. Swap the database layer, rewrite the billing module, keep the auth you have already audited. One practical pre-commitment before you buy: write down the three parts of the kit you expect to replace. If that list starts long, you are paying to discard code; if it stays short, you bought leverage. Almost nobody faces a pure binary; the real decision is which pieces you inherit on day one. The full return-on-investment argument for inheriting them is in is a SaaS boilerplate worth it, and if you take the buy path, Startplate’s tier structure is on the pricing section.

How much time does building a SaaS from scratch actually take?

Realistically three to six months of full-time work for an experienced developer building a conventional SaaS MVP from an empty repository — and six to twelve months or more once team accounts, roles, and admin tooling enter scope. The same product built on an in-place foundation typically reaches a chargeable version in four to ten weeks.

Here is where the months go, in honest ranges. Authentication done properly — sessions, verification, resets, OAuth callbacks, rate limiting, 2FA — runs 80–160 hours. Subscription billing with webhook verification, retries, dunning, and a customer portal runs 60–120. A multi-tenant schema with migrations and invitations runs 80–200. Email deliverability (SPF, DKIM, templates, suppression), deployment, CI, secrets, and a basic admin layer add another 80–200 combined. That is 300–680 hours of infrastructure before your first product feature — eight to seventeen full-time weeks — and the feature build, design passes, QA, and beta cycle then stack on top, which is how honest projects land in the three-to-six-month band. Part-time work does not divide the calendar evenly: ten evenings-and-weekends hours a week stretch the same effort toward nine to eighteen months, because re-entry cost and context switching eat the edges of every session.

Two variables move the number more than anything else. Scope: a single-user tool with one payment plan is the bottom of the range; organizations, roles, admin, and custom integrations push the top. Team: an experienced contract developer bills typical market rates of $50–$150 per hour, so the foundation layer alone quotes at five figures before feature work. Then multiply by revision: features get built twice when version one misunderstood the user, and integrations get rebuilt when sandbox behavior differs from production — a plan that counts each major piece once is already optimistic, and the standard mitigation is doubling the estimate while holding a quarter of the calendar as buffer. That is why the build-versus-hire question is worth its own analysis in should I hire a developer to build my SaaS.

What are the downsides of using a boilerplate?

The real downsides are unfamiliar abstractions you did not choose, code you must read before you trust it, framework lock-in, unused surface area, and the temptation to ship authentication you never audited. None of these are fatal, but each has a price that should go into your decision rather than your surprises.

Walk them concretely. Learning curve: every kit encodes opinions about folder structure, state flow, and data access; internalizing them costs a few days and a hundred small lookups, and if you bring in AI coding assistance, it inherits those opinions too — good when the structure is sound, confusing when you cannot tell the agent’s invention from the kit’s convention. Abstraction mismatch is the expensive one: if the kit’s role model or tenancy assumptions differ from what your product needs, unlearning and rewiring costs more than writing it once, which is why trial-running the starter before committing pays for itself — kits with a working quickstart let you fail fast on day one instead of week three. Then there is dead weight: marketing pages you replace, components you never render, dependencies you carry. And the audit debt — auth, billing, and permissions code you inherited without understanding is liability you own whether or not you read it; budget an afternoon to trace sessions, confirm webhook signatures are verified before handlers mutate data, and run the included test suite so you know it is green before you extend it.

Cheap insurance for all of it: fork the starter into your own repository on day one, pin your dependencies, and treat upstream changes as reviewed pull requests instead of automatic updates. For fairness: these costs attach to all inherited code, including the open-source libraries you would assemble anyway. The question is only whether the bundle is documented enough to pay down the curve — options at both price points are in free open-source SaaS boilerplates.

When is it better to build your own SaaS foundation?

Build your own foundation when infrastructure is the differentiator you sell, when customers or regulators require full knowledge of every data path, or when you have built the same base three times and it has quietly become a product of its own. Those are the cases where foundation work compounds instead of merely costing.

The first case is infrastructure products: if you are selling a database layer, a scheduler, an SDK, or developer tooling, the plumbing is the value proposition, and renting someone else’s assumptions caps what you can claim about it. The second is compliance: teams handling card data directly or operating under strict audit regimes need to know precisely where every credential and record travels — though even they typically assemble from audited libraries rather than writing cryptography or session management from zero. The third is the repeat studio: after shipping several client projects with the same needs, the arithmetic flips, because an internal kit amortizes across every future deliverable — a point where agency licensing terms start mattering as much as code. The fourth is deliberately selfish: infrastructure depth is career capital for consultants and senior engineers, and the months spent building it convert into expertise you bill for later.

One more case that resembles build-your-own but is not: the team that has already paid twice for the same missing feature. The second time an off-the-shelf kit lacks a piece you need, the arithmetic quietly starts favoring a foundation you control. Also note the option that is neither: a mature codebase you already understand. Rewriting a working foundation on new conventions to “start fresh” is rarely justified, and the decision framework for that trap is covered in the boilerplate ROI guide linked above. Whichever route you take, keep one rule — even scratch builds should use proven libraries for auth primitives and payment clients. Building from scratch means owning the architecture, not reinventing the crypto.

Do boilerplates slow you down later when scaling?

Not inherently — most scaling pain comes from hitting a kit’s abstraction ceiling, meaning the moment real usage demands a model the kit did not anticipate, rather than from having started with one. The ceilings are predictable, and choosing a kit that already models your likely constraint pushes that wall years into the future.

The three ceilings worth naming. Tenancy: a single-tenant kit forcing a later organizations retrofit means rewriting primary keys, authorization, and the billing subject — the hardest wall in this list, and the reason team support should be evaluated before purchase, not after. Billing: fixed subscription plans are easy; usage-based or metered pricing needs a model many minimal kits never had. The defense is an adapter at the seam — keep providers behind one interface so a new rail slots in without touching product code; Startplate’s shared payment layer, for example, defaults to Dodo Payments with Stripe and Lemon Squeezy adapters, and the pattern is documented in the payments guide. Infrastructure: free tiers, single regions, and no queues eventually give way to paid plans, caching, and background jobs — but that work is yours regardless of how the project started, and none of it is encoded in any boilerplate.

The counter-evidence matters: products launched on kits reach real revenue routinely, because the bottlenecks that actually appear at scale are database indexes, N+1 queries, missing caching, and synchronous work that should be queued — all author-owned decisions, not inheritance damage. Two habits keep a kit from becoming drag: keep your domain logic in clearly separated modules so kit code and product code evolve independently, and take upstream updates while they are cheap — the update policy is a buying criterion for exactly this reason, and Startplate’s terms are spelled out under updates and license. Ask every vendor one question that surfaces ceilings early: what changed in your last two major versions, and what did users have to migrate?

The short version

The buy-versus-build decision comes down to product shape, timeline, and how much of the foundation you are willing to understand — conventional subscription products favor a kit, unusual infrastructure favors scratch. From an empty repo, plan on three to six months full-time for a conventional MVP, with foundation work alone eating two to four of them. Boilerplates have real costs — learning curves, lock-in, audit debt — but each has a mitigation, and scaling problems trace back to unmodeled constraints rather than to starting from inherited code. Pick the path whose failure modes you would rather debug.