We run a boilerplate directory, and the honest position is that starter kits are the wrong choice for a meaningful minority of projects. A boilerplate trades your unfamiliarity with someone else's architecture for the weeks it would take to build that architecture yourself. When the architecture does not fit, or when there was little to save, that trade goes negative. Here is how to tell before you spend the money and the week.
What you are actually buying
You are not buying code. Code is the cheapest thing in the transaction. You are buying integrated decisions someone made, tested against real users, and then maintained: which auth provider, how sessions are stored, how a webhook maps to an entitlement, what happens when a subscription lapses mid-cycle, how a team invite works when the invitee already has an account. Each has a wrong answer that is not obviously wrong for two months. For the concept before the critique, what is a SaaS boilerplate covers the basics.
The cost side gets stated less often. You inherit an architecture you did not design and must learn it before you can move quickly inside it. That learning is real, unglamorous work, and it lands when you are most impatient to ship. For a kit matching your mental model it might be two days. For one that does not, it is a tax on every feature, because every change starts with guessing where the author would have put this.
The break-even is not how much code you get. It is whether the kit's assumptions match your product's shape. Where they match, you get decisions for free. Where they do not, you get decisions to undo, and undoing an integrated decision in someone else's codebase is consistently more expensive than making it yourself in an empty repository.
Case 1: your product is not shaped like a SaaS
Essentially every kit assumes the same skeleton: a user signs up, subscribes to a recurring plan, and works inside a dashboard, possibly with teammates in a tenant. That describes a lot of software, which is why the kits exist. It does not describe a CLI tool that authenticates with a token and has no interface, a browser extension whose entire surface is a popup, a two-sided marketplace where the hard problems are payouts, disputes, and identity verification, or a data pipeline whose users are three internal analysts.
The test is concrete: count how many of auth, subscriptions, teams, and a dashboard you need on the roadmap you believe in. Three or four, and the kit is doing real work. Below two, you are buying a scaffold that mostly needs deleting, and deleting from an integrated codebase is slower than it looks because the pieces reference each other. The marketplace case is sharpest: you use the auth, throw away the subscription layer, then build the payout flow yourself, which was always the hard part.
One honest exception. Some of what a kit provides is plumbing rather than product shape: deploy configuration, transactional email that renders in Outlook, error tracking wired up, an SEO-capable marketing site. If you would genuinely build all of that, a kit can pay for itself on plumbing alone even when the domain model is a poor match. If your thing has no marketing site, no transactional email, and deploys as a binary, start empty.
Case 2: you are validating, not building
A boilerplate is engineered for durability: proper session handling, migrations, webhook idempotency, tenant isolation. Those matter enormously for software still running in two years and not at all for software whose job is to find out whether anyone wants the thing. At the validation stage you are buying insurance on an asset you may never own, paying in setup time during the phase where speed is the only thing that counts.
The right tools for that phase are prototypes and app builders: something you can put in front of ten people this week, that breaks under load you will never have, that you expect to throw away. The comparison is in boilerplate vs AI app builder, and the short version is that they serve different stages, though they are marketed as competitors.
The sequencing that works: validate cheap, then buy the foundation once there is something worth sustaining. People invert this because buying a kit feels like commitment and commitment feels like progress. A well-architected product nobody wants is a more expensive failure than a scrappy one.
Case 3: the compliance or hosting constraints are hard
Some constraints are not negotiable and are decided before the first line of code. On-premise delivery, where the customer runs your software in their own infrastructure. Air-gapped deployments with no outbound network access. Data residency rules dictating which country a row sits in. Regulated industries where you face an audit and every component in the auth path must be something you can explain and evidence.
Kits assume managed vendors, reasonably, because managed vendors are the right default for most products. Auth is a hosted provider, email goes through an API, payments are a third-party SDK woven through the billing logic. Under a hard constraint every one of those has to be unpicked from code written assuming it never would be, which is worse than starting deliberately with self-hosted equivalents chosen for the constraint. You pay twice: once for the kit, once for the extraction.
The enterprise variant is a customer contract dictating the stack outright: a specific cloud, a specific identity provider, a specific database because that is what their DBAs support. When the stack is given to you, a kit built on a different one has nothing to offer.
Case 4: the time saved is not the point
You already have a working foundation
If this is your second or third product and the first works, the base to build on is usually your own. Not because it is better engineered than a commercial kit, it probably is not, but because you know where everything is and the conventions are already in your head. The speed advantage of a kit comes from skipping decisions, and you already made those and shipped them.
The trap is specific and expensive: adopting a new architecture for product two while product one runs on the old one. Every shared concern now exists twice, in two dialects, and every engineer moving between them pays a context switch. Security patches get applied twice by someone who remembers both. Onboarding means teaching two codebases. That cost accrues quietly for years and never shows up in the decision that caused it.
Once the pattern has actually repeated, extracting a shared internal base is worth doing. Extract it from working code rather than a design, so it holds the decisions that survived contact with users rather than the ones that sounded right.
Learning is the actual goal
If the point of the project is to understand how sessions work, how OAuth flows behave, or what a billing state machine has to handle, a boilerplate hands you the answer and quietly removes the lesson. You read code that already works, feel like you understood it, and find the gap the first time you debug it under pressure. Understanding comes from getting it wrong and fixing it, and a kit exists specifically to stop you getting it wrong.
Be honest about which project this is, because "I want to learn it properly" is the most common disguise procrastination wears. The test: is a user waiting. If someone is waiting for the product, learning is not the goal and you are stalling, so take the kit and learn from something that is not blocking a delivery. If nobody is waiting, build it from nothing, badly, the first time.
Case 5: the kit is unmaintained or badly structured
A stale kit is worse than no kit. You inherit an architecture built around SDK versions that moved on, auth patterns the provider now discourages, and a payments integration written against an API shape that changed. You pay the full cost of learning someone else's decisions and get none of the benefit of them being current, and nobody will fix it, because the reason it is stale is that the author left.
The checks take fifteen minutes and belong before payment. Last commit date, and whether recent commits are real changes or README edits. A changelog showing dependency updates tracking upstream releases rather than sitting six months behind. Whether the code follows one pattern throughout or three, which tells you whether it was designed or accumulated. And whether an agent can navigate it, a legitimate quality signal because what makes code legible to an agent is what makes it legible to you: consistency, clear boundaries, small modules, explicit types at the edges. Those form the rubric in the AI agent ready boilerplate checklist.
We score kits on exactly this in our Agent Ready category, and the scoring exists because the variance is large. Two kits at the same price claiming the same features can differ by a week of your time in how quickly you can safely change them. The feature list is what everyone competes on; the structure determines your velocity.
The case where "the agent can write it" is not enough
The 2026 objection deserves a straight answer: agents can generate auth, billing, and a dashboard in an afternoon, so why pay for a kit. The premise is true. An agent will produce all of that, and it will look right.
The value moved. It used to sit in the typed code, because typing it took weeks. It now sits in accumulated correctness: the webhook retry that is idempotent because someone got double-charged once, the session invalidation on password change that was missing until a security report arrived, the tenant scoping at the query layer rather than sprinkled through handlers. None of that is visible in the generated version, because it is defined by absence. Generated infrastructure is unreviewed infrastructure until you review it, and reviewing auth and billing properly is slower than writing them, which is why almost nobody does it.
The practical answer is usually both. Take a maintained foundation for the parts where correctness accumulated through other people's incidents, and generate aggressively above it, where your product lives. That is the workflow in starting a SaaS with AI agents in 2026, and it holds up better than the purist version in either direction.
If you skip the boilerplate, skip it deliberately
Deciding against a kit does not exempt you from the problems it solves. It means you own them, and there is a minimum to get right regardless. Auth boundaries enforced server-side on every protected route, in one place rather than per handler. Entitlements derived from webhook events and stored in your database, never inferred from a client claim or a cached checkout response. Tenant isolation at the data access layer, because a per-endpoint approach fails the first time someone adds an endpoint in a hurry. And a deploy pipeline that runs your checks, because manual deploys stop being careful around week six.
Those four are where the incidents happen, and each has a decision underneath worth making on purpose: the SaaS auth decision guide, the SaaS payments decision guide, and the SaaS database decision guide walk the tradeoffs so you choose rather than default.
Then write the conventions down before generating anything. Starting from an empty repository with an agent means the first hundred files establish patterns nobody chose, and every file after imitates them. Half an hour naming your directory layout, data access pattern, and error handling produces a codebase still coherent at file four hundred. Our AGENTS.md templates give you the structure, and the AGENTS.md generator drafts one from code you already have.
Frequently Asked Questions
Is a boilerplate worth it if I am an experienced developer?
Usually yes on time, sometimes no on fit. Experience means moving faster through unfamiliar code and judging a kit's decisions better, which raises the value of buying one, but it also means stronger opinions, and friction with architecture you disagree with compounds. The deciding question is whether you would make substantially the same decisions the kit made. If yes, buy it. If you would fight it on auth or data modeling, you will spend more undoing than building.
Can I just have AI generate a boilerplate for me?
You can generate a scaffold and it will work. What you get is a one-time snapshot with no maintainer, a different asset than a maintained kit. When the payment SDK ships a breaking change, when the auth provider deprecates a flow, when a CVE lands in a dependency, nobody updates your generated code and no changelog tells you it happened. Over a year that is several afternoons of upgrade work you do alone, plus the risk of never noticing.
What if I only need auth and payments?
That is the strongest case for a kit, not the weakest. Auth and billing are where correctness accumulates from other people's production incidents and where failure modes are expensive, so inheriting a tested implementation of both is exactly the trade a boilerplate is good at. If you genuinely do not want the rest, compose a managed auth provider with a billing library and write the webhook to entitlement mapping yourself. That is a day or two of careful work, and the part worth being careful about anyway.
How do I know if a boilerplate fits my product?
Run the assumption-match test: list what the kit assumes, signup, recurring subscriptions, teams inside a tenant, a dashboard as the primary surface, one database, one deploy target, and mark each true, false, or irrelevant. Mostly true means buy. Several false means it will fight you where it matters most. If the stack underneath is still open, the tech stack recommender narrows it down, and our Agent Ready category filters to kits whose structure will not slow you down later.
Should I build my own boilerplate?
Only after the third similar project, and extract it from working code rather than designing it upfront. The underestimated cost is maintenance: an internal base is a product with you as sole maintainer and no revenue, so every dependency update, framework migration, and security patch is your weekend. Worth paying when it saves real time across several active projects, not worth it for two. Before the third project you do not know which parts generalize, and a base built on guesses becomes something you work around rather than with.
