The thesis: we run a boilerplate directory, and the honest position is that starter kits are wrong for a meaningful minority of projects. A boilerplate trades your unfamiliarity with someone else's architecture for time saved. When the architecture does not fit, or when there is 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
- Reframe the purchase: not code, but integrated decisions and maintained integrations. Reference /what-is-a-saas-boilerplate for readers who need the concept.
- State the cost side plainly: you inherit an architecture you did not design and must learn before you can move fast in it.
- Argue the break-even is roughly whether the kit's assumptions match your product's shape.
Case 1: your product is not shaped like a SaaS
- Argue most kits assume signup, subscription, dashboard, tenant. A CLI, a browser extension, a marketplace with two-sided payouts, or a data pipeline gets almost nothing from that.
- Give the test: count how many of auth, subscriptions, teams, and dashboard you actually need. Below two, the kit is overhead.
- Note the exception where a kit is still worth it for the deploy and email plumbing alone, and when it is not.
Case 2: you are validating, not building
- Argue that a kit is the wrong tool for finding out whether anyone wants the thing, because it optimizes for durability you may never need.
- Point at prototypes and app builders as the correct tool for that phase, and reference /blog/boilerplate-vs-ai-app-builder.
- State the sequencing: validate cheap, then buy the foundation once there is something to sustain.
Case 3: the compliance or hosting constraints are hard
- Name the cases: on-prem delivery, air-gapped deployments, data residency requirements, regulated industries with audit obligations.
- Argue that kits assume managed vendors for auth, email, and payments, and unpicking those assumptions costs more than starting deliberately.
- Add the enterprise case where a customer contract dictates the stack.
Case 4: the time saved is not the point
You already have a working foundation
- Argue the second product from the same founder should usually extend an existing internal base rather than adopt a new one.
- Cover the specific trap of running two different architectures in one company.
- Reference the option of building your own reusable base once the pattern is proven.
Learning is the actual goal
- Argue that if you are building to understand auth, sessions, or billing, a kit hands you the answer and removes the lesson.
- Distinguish this honestly from procrastination dressed as learning, and give the test for which one you are doing.
Case 5: the kit is unmaintained or badly structured
- Argue a stale kit is worse than no kit, because you inherit deprecated integrations and no one to fix them.
- Give the checks: last commit date, changelog, whether generated code follows one pattern, and whether an agent can navigate it. Link /blog/ai-agent-ready-boilerplate-checklist.
- Point at /categories/Agent-Ready for kits scored on exactly this, and argue that scoring exists because the variance is large.
The case where "the agent can write it" is not enough
- Address the 2026 objection head-on: agents can generate auth and billing, so why buy.
- Argue the value moved from typed code to accumulated correctness, and that generated infrastructure is unreviewed infrastructure until you review it.
- Reference /blog/start-a-saas-with-ai-agents-2026 for the workflow that combines both.
If you skip the boilerplate, skip it deliberately
- Give the minimum you must still get right: auth boundaries, entitlement from webhooks, tenant isolation, and a deploy pipeline.
- Point at the decision guides: /blog/saas-auth-decision-guide, /blog/saas-payments-decision-guide, /blog/saas-database-decision-guide.
- Argue for writing the conventions down before generating anything. Link /templates/agents-md and /free-tools/agents-md-generator.
Frequently Asked Questions
Is a boilerplate worth it if I am an experienced developer?
- Answer: usually yes for time, sometimes no for fit, and give the deciding question.
Can I just have AI generate a boilerplate for me?
- Answer: you can generate a scaffold, but you get a one-time snapshot with no maintainer, and explain what that costs over a year.
What if I only need auth and payments?
- Answer: that is the strongest case for a kit, and describe the lightweight alternative when the rest is genuinely unwanted.
How do I know if a boilerplate fits my product?
- Answer with the assumption-match test and point at /free-tools/tech-stack-recommender and /categories/Agent-Ready.
Should I build my own boilerplate?
- Answer: only after the third similar project, and explain the maintenance cost people underestimate.
