Every time I decide to build something, the same argument runs in my head. Start from a SaaS boilerplate and save months, or build from scratch and have it exactly the way I want. I have done it both ways more times than I can count, so let me save you some of the trips.
What "from scratch" actually costs
From scratch sounds pure. No one else's decisions, no code you did not write, total control. And for the first week it feels great.
Then you spend the next two months building the stuff that every single app has. Sign up and log in. Password resets. Billing. The multi-tenant plumbing that keeps one customer's data away from another's. Permissions. The boring, dangerous, non-negotiable 80% that is identical across basically every SaaS on earth. None of that is your idea. None of it is why you started. And getting it wrong, especially the security parts, is how you end up in a very bad week.
I have burned months here. The worst part is that when you finally finish the generic plumbing, you are exactly at the starting line everyone else who used a boilerplate reached in an afternoon.
What a boilerplate actually costs
A good boilerplate hands you that whole 80% already built and already tested by more than just you. Auth, billing, tenancy, permissions, the plumbing, done. You start at the interesting part, the 20% that is actually your product.
The honest cost is that you inherit someone else's decisions. Their structure, their patterns, their way of naming things. If the boilerplate is a mess, you have adopted a mess, and untangling a bad foundation can cost more than starting clean. So the boilerplate is only a win if its actually good, and "actually good" means battle-tested, readable, and something you can understand well enough to build on.
That is the real question. Not "boilerplate or scratch" in the abstract. It is "is this specific foundation good enough that inheriting it beats building it."
Join the Seedly owners community.
Owners trade setups, share add-ons, and swap playbooks. See what people are building before you commit.
What the generic 80% actually weighs
"The boring 80%" is easy to wave at and easy to underestimate, so here is the thing I shipped, measured.
Seedly CRM runs on 201 database tables with 608 indexes across them, roughly 2,700 backend functions, and over 1,400 automated tests whose only job is proving one tenant cannot read another tenant's data. That last number is the one to sit with. Fourteen hundred tests, for one requirement, that no customer will ever thank you for getting right and every customer will leave you over if you get it wrong.
None of that was the idea. None of it is why I started. It is the floor you have to build before you get to the part that is yours.
Two more numbers for scale. Forking a working codebase and shaping it into my product took 900+ hours and roughly $1,600 in AI tokens over about three months. Building the same thing from scratch would have run 2,000+ hours, and at the end of it I still would not have had feature parity with what I started from. That gap, roughly 1,100 hours, is the price of laying plumbing by hand.
What starting from a foundation actually looks like
The clearest proof I have of this is not mine.
Kerry, who bought the codebase, delivered a $27,212.50 custom development project for one of his clients using it as the foundation. That took him about 60 hours of development time and $200 to $300 in AI credits. He is not a bigger team than me and he did not have a year.
Sixty hours to a $27k deliverable is only possible because the auth, the tenancy, the permissions and the plumbing were already there and already tested. From a blank folder, sixty hours does not get you to a login screen you would trust with a client's data.
That is the whole argument in one invoice. The foundation is not what you are building. It is what lets you get to what you are building.
How I decide now
My rule is simple after enough scars. If the thing I want to build is mostly the generic 80% with a small twist, a boilerplate wins every time and it is not close. Building auth and billing again to express a small idea is a waste of the only thing I cannot buy more of, which is time.
I only build from scratch when the core of what I am making is genuinely unlike anything a boilerplate assumes, so their foundation would fight me the whole way. That is rare. Most of the time, the thing that makes my product mine lives in that top 20%, and everything under it is plumbing I should not be laying by hand.
The AI angle changes this too. People think AI means you can afford to build from scratch now. In my experience it is the opposite. AI makes shaping a solid foundation into your product incredibly fast, and it makes generating a fragile version of the plumbing dangerously easy. Start from something proven and point the AI at the 20%.
Common questions about boilerplates versus building from scratch
Is a SaaS boilerplate better than building from scratch?
It depends on one thing, which is whether the core of your product is unlike what the boilerplate assumes. If your idea is mostly the standard 80% with a twist, a boilerplate wins and it is not close. If your foundation would fight you the whole way, build. That case is rarer than people think.
How long does building a SaaS from scratch actually take?
For anything with real multi-tenancy the honest answer is months before you reach the interesting part. Forking a working codebase and shaping it into my own product took 900+ hours over about three months. From scratch would have been 2,000+ hours, and I still would not have had feature parity with what I started from.
What does the generic 80% of a SaaS include?
Sign up and log in, password resets, billing, permissions, and the multi-tenant plumbing that keeps one customer's data away from another's. On the CRM I ship, that layer is 201 tables, 608 indexes, roughly 2,700 backend functions and over 1,400 automated tests written purely to prove tenant isolation holds.
Does AI mean you can build from scratch now?
In my experience it argues the other way. AI makes shaping a solid foundation into your product extremely fast, and it makes generating a fragile version of the security plumbing dangerously easy. The failure mode is not slow code, it is confident code that has never been tested by anyone but you.
What makes a boilerplate worth inheriting?
That it is battle-tested, readable, and something you can understand well enough to build on. You are adopting someone else's structure and naming, so a bad foundation costs more than starting clean. Ask whether the thing is actually good before asking whether boilerplates are good.
My rule after enough scars
From scratch is not more "real" than a boilerplate. It is just slower, and the time goes into work that was never your edge. Unless your core is truly exotic, start from a foundation that is genuinely good and spend your months on the part only you can build.
I make the same case specific to CRM in why forking beats building from scratch, and the reality of building on a foundation with AI is in how I built my own CRM with AI.
Skip the plumbing. Build the part that is yours.
