Guide
SaaS Boilerplate vs Building From Scratch
The feature you want to build is the fast part. The foundation under it is about thirty working days, and that number is the whole argument, so it is printed below with its source.
Every vendor on this market, ours included, has a reason to make building from scratch sound worse than it is. So this page does the arithmetic with numbers you can check, names the cases where scratch wins, and leaves the countdown timer off. The saas boilerplate vs building from scratch question is a division problem once the inputs are honest, and the inputs are the interesting part.
Two things before the numbers. First, "from scratch" here means writing the SaaS foundation yourself: accounts, sessions, organizations, roles, invitations, billing, transactional email, and an admin screen. Nobody is suggesting you write a web framework. Second, the estimates come from the build estimates published on each Hype Stack pack page, which are the days one experienced developer would need to write that pack from nothing. They are the numbers we use to decide what to build next, so they are as honest as we know how to make them, and you should still argue with them.
The time math
A B2B SaaS foundation, in working days
- 15 days15
Accounts, sessions, organizations, roles, and an admin app
Signup, login, password reset, email verification, org switching, role checks on every route, invitations, and the screens an operator needs to look a customer up.
- 10 days25
Subscription billing
Checkout, plans, customer portal, and webhook handling that survives Stripe retrying, reordering, and duplicating events. The last clause is where the days go.
- 5 days30
Real-time notifications
WebSocket push, channels, in-app delivery, read state, and a broadcast screen in the admin app.
- 1 day31
A dashboard layout
Sidebar that collapses, org switcher, breadcrumb header, responsive at 375px.
At a $400 day rate
$12,400
An assumption, and yours to change. The 31 days are the fixed part.
Hype Stack Solo
$299 a year
All four rows as packs. The template underneath is free.
One-time kits
$199 to $299
ShipFast, TurboStarter, Supastarter, at their listed single-developer prices.
What none of them cover
Your product
The feature customers pay for is the same amount of work either way.
Days are the estimatedBuildDays published on the SaaS Starter, Billing (Stripe), Notifications, and Basic Layout pack pages. Prices are as listed on each vendor's page at the time of writing.
Thirty-one days is one developer, uninterrupted, who has built these things before. A first-timer is slower, mostly on billing, because webhook idempotency is the kind of bug that looks fine until the first double charge. A team of three is not three times faster, because tenancy and auth are the pieces everybody has to agree on before anyone can build on them.
Divide either price by the days and the kit wins by an order of magnitude for anyone who is paid to write software. That is not the interesting result. The interesting result is the four cases where the division comes out the other way, and they are next.
When scratch is the right call
Build the foundation yourself when any of these is true
- The infrastructure is the productIf you are selling auth, billing, or tenancy, buying someone else's is buying your competitor. Write it.
- Compliance dictates the auth flow line by lineSome regulated products have to prove every branch of the login path. Owning a kit's code helps here, but a kit written for a different regime may cost more to audit than to replace.
- The team already maintains these piecesA company on its third product usually has an auth service and a billing library it trusts. A kit is dead weight next to that, and the honest advice is to reuse what you have.
- The app genuinely needs none of itMore internal tools than people admit have one user, no billing, and no tenancy. A kit adds thirty days of structure to a tool that needed three.
If none of these apply, the ledger above is your answer, and the remaining question is which kind of kit.
What you write yourself either way
This is the part vendors skip, and it is the part that makes the rest credible. A kit gives you the foundation. Your product is still yours to write, and it is a specific list, not a hand wave.
Yours, with or without a kit
The feature customers pay for
No kit knows what your product does. The screens, the data model for your domain, and the rules that make it useful are the same amount of work on a kit as on a blank repo. The kit's job is to make sure that is the only thing left.
The permission model beyond roles
Kits ship owner, admin, and member. Your product probably needs "can approve invoices over $10k" or "can see this client and not that one". That is a status column and a check in middleware, and it is yours.
The pricing logic
Billing packs handle subscriptions and webhooks. Whether a seat is charged the day it is added, prorated, or counted at month end is a business decision the pack cannot make for you.
Operations
Backups, error reporting, a status page, and someone reading the support inbox. Kits wire Sentry and a health check. Running the thing is a job, not a feature.
Three beliefs worth correcting
If I buy a boilerplate I am tied to the vendor, so scratch is the safe choice.
A kit that is a git repository or a CLI writing files into your repo gives you code you own outright, with no runtime call to the vendor. A hosted platform or an npm package does not. Ask which one you are buying; the Hype Stack template is MIT and the packs are copied source, so deleting the CLI changes nothing about the app.
Writing auth and billing myself means I know how they work when they break.
You will not know a copied billing flow the way you would know one you wrote. But a kit that lands as source in your repository is code you can read, step through, and edit before the first incident, which is a different situation from a black-box package. The thirty days buy understanding you can also get in an afternoon of reading.
Building it myself costs nothing but time, and I have time.
Thirty-one days is a month of a product not existing. For a funded team that is salary; for a solo founder it is a month of not talking to customers. The kit price is small next to either, which is why the division above is not close for most people.
The first belief is the one most worth checking against the specific kit, because it is true of some and false of others.
Three ways to not build it from scratch
If the ledger sent you towards a kit, there are three kinds, and they sit on an axis from "buy everything" to "buy nothing".
How much arrives, and how
Full kits
ShipFast, Supastarter, TurboStarter. Clone once, delete what you do not need, merge upstream by hand.
Composable template
Hype Stack. An MIT template with nothing in it, and a CLI that writes the packs you name into it as source.
Scaffolds
create-t3-app. Typed wiring and a database, and every row in the ledger above is yours to write.
Positions are editorial. The middle marker is ours, and the two ends are good answers for the products they suit.
Which of these is your situation?
Build it when one of the four conditions above is true.
- The foundation is the product, or the team already owns one it trusts
- Budget the 31 days honestly, and more for a first billing integration
Clone one when the feature list is fixed and the product is one web app.
- Fastest to a first screen, and a one-time price
- Plan for pruning, and for merging upstream updates by hand
Compose when the feature list will change, or the product has more than one surface.
- Only the packs you chose in the tree, added with the same command in month six
- Web, admin, mobile, extension, and desktop already wired in the free template
The middle column is not a compromise. It is the right answer for a fixed list on a web app, and the wrong one if that list is going to move.
Below is the stack the ledger priced: the Better Auth SaaS starter, the basic layout, Stripe billing, and real-time notifications. The four rows, as packs, written into a template that costs nothing.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.