SaaS Build vs Buy: What You Should Never Write Yourself
Eight subsystems every SaaS needs, which of them are commodity, and the one question that decides each
Startups building a SaaS product spend their first year rebuilding subsystems that were solved a decade ago, and they do it because every one of those subsystems looks small from the outside. The turn is that none of them are, so the roadmap quietly fills with authentication edge cases and invoice rounding while the thing customers were promised sits unbuilt, and the company burns a year of runway producing a product that is identical to its competitors except for having a worse billing system. By naming the eight subsystems every SaaS needs, showing which of them are commodity, and giving you a decision rule that does not depend on anybody's pricing page, I want you to leave able to answer this for your own product in an afternoon.
The reason this is so hard to see from inside the company is that every individual decision along the way is defensible, because building your own authentication really is about a week, and your own billing really is about two, and your own notification fan-out really is a few days, so nobody in the room is lying or even being especially optimistic, and yet the year still disappears, because each of those honest estimates was an estimate of the build and never of the ownership, which is the part that has no end date and no owner and turns up later as interruption rather than as work anybody planned.
Here is what that costs, in the vocabulary a founder recognises:
- The features you were funded to build slip a quarter, because the team is busy with plumbing that no customer will ever compliment.
- Your first enterprise deal stalls on SSO, audit logs or data residency, none of which your hand-rolled identity layer anticipated.
- You acquire a permanent maintenance obligation with no owner, which surfaces as interruptions rather than as planned work.
If you want to skip the framing, what counts as commodity, the eight subsystems and the build-or-buy matrix are the useful part, the decision rule is how you apply it to something not on the list, the common mistakes are how it goes wrong, what it costs you in runway is why any of it matters, and the questions are at the bottom.
What counts as a commodity subsystem?
A commodity subsystem is any part of your product that a competitor could buy off the shelf and be no worse off for having bought. It is defined by replaceability rather than by difficulty, which is the distinction that trips people up, because plenty of commodity subsystems are genuinely hard to build well. That is precisely why somebody has already built them.
The test is not "could we write this". You almost certainly could. The test is whether writing it changes anything a customer would notice, and for most of the plumbing in a SaaS product the honest answer is that it does not.
The eight subsystems every SaaS needs
Nearly every SaaS product, regardless of what it actually does, needs the same eight things underneath the part that makes it interesting.
- Authentication, which is the business of proving somebody is who they claim to be, and which is far larger than a login form once you count password reset, verification and revoking a session that has gone bad.
- Authorisation, meaning the rules about what each person is allowed to touch once you have let them in, which is a different problem entirely and is usually treated as the same one.
- Organisations and teams, because your buyer is a company while your user is a person, and whether one person can belong to two companies is a decision that reaches into every table you will ever write.
- Billing and subscriptions, which means plans, proration, dunning, failed cards and tax, none of which are interesting and all of which are regulated.
- Notifications, covering email and in-app delivery along with the preferences that decide who hears about what and how often.
- File storage, which is uploads, access control, and the signed URLs that somebody always forgets to expire until the day somebody else notices.
- Analytics, both the record of what your customers did and the far harder question of what you intend to do about it.
- AI integration, which has moved from a differentiator to a table stake fast enough that most roadmaps have not caught up with it yet.
Write that list down and mark the ones your team has built or is currently building. That count, multiplied by the weeks each took, is the arithmetic this post is about. I am not going to give you a percentage, because I would be making it up and you can measure your own.
Which of them should you actually build?
Most of them, you should not. The table is the part of this page worth reading twice:
| Subsystem | Default | Why | Build it yourself when |
|---|---|---|---|
| Authentication | Buy | Password reset, SSO, MFA and session revocation are years of absorbed edge cases | Identity must live in your own database for tenancy or residency reasons |
| Authorisation | Build | Your permission model is your domain model, and no vendor knows it | Almost always. Buy only the enforcement primitives, never the policy |
| Orgs and teams | Build | Whether a user can belong to two companies is a product decision, not a library one | Almost always, and get it right early because it reaches every table |
| Billing | Buy | Proration, dunning, tax and invoice regulation are a full-time job that is not your job | You have usage metering the vendor genuinely cannot express |
| Notifications | Buy the transport, build the preferences | Delivery is commodity, but what a user wants to hear about is your product | Never build the transport. Building the preference layer is normal |
| File storage | Buy | Object storage and signed URLs are solved and cheap | You have residency or encryption requirements the vendor will not meet |
| Analytics | Buy first, build later | Early on you need answers, not a warehouse | Once the questions are specific to your domain and asked constantly |
| AI integration | Buy the model, build the context | The model is a commodity, and what you feed it is not | Never train your own to start. The differentiator is retrieval, not weights |
Notice that the two you should almost always build, authorisation and organisation modelling, are also the two most commonly bought, usually by adopting whatever shape the auth vendor imposed. That is the expensive mistake in this whole area, and it is expensive precisely because it is invisible for about eighteen months.
The rule for anything not on that list
Two questions, in this order, and the second only matters if the first says build.
1. Would a customer notice if a competitor's version replaced this?
If no, buy it. Nobody has ever switched SaaS products because of whose authentication library was underneath. If a customer would notice, you are looking at your actual product and you should build it.
2. Can you say concretely what the vendor cannot do?
This is the question that separates a real constraint from a preference. "Their model does not fit ours" is a preference until you can finish the sentence with something specific, like usage metering per API call with mid-cycle plan changes, or identity that cannot leave your own database because of where your customers are regulated.
If you cannot finish that sentence, you do not have a requirement. You have a taste, and taste is an expensive thing to fund at seed stage.
How this goes wrong in practice
Why did our "one week" auth build take three months?
Because the build was a week and the ownership was the rest. Password reset, email verification, session revocation, rate limiting on the login endpoint, the first SSO request, an audit trail somebody in procurement asked for, and then the review after a near miss. Each arrives separately, each is small, and none of them were in the estimate because the estimate was of the happy path.
Why does our first enterprise deal keep stalling?
Usually because the buyer asked for SAML, SCIM provisioning, audit logs or a data residency guarantee, and the identity layer built for consumer signup has no concept of any of them. This is the most expensive form this mistake takes, because it converts an engineering decision into a stalled contract, and it lands at exactly the moment revenue was supposed to arrive.
Why is our permission logic scattered across the codebase?
Because authorisation was inherited from whatever the auth vendor offered, usually flat roles, and your real model was never flat. So the gaps get filled with conditionals at the call site, which is where permission logic goes to become unauditable. Buy the enforcement, build the policy, and keep the policy in one place where it can be read.
Why did buying turn out to cost more than we thought?
Because the pricing page prices the subscription and not the integration, the ceiling, or the exit. The fix is to ask what leaving costs before you arrive: a subsystem you could migrate away from in a fortnight is a different risk from one welded into every table you own, and the two deserve different levels of scrutiny at the point of choosing.
Frequently asked questions
What should a SaaS startup build versus buy? Buy anything a competitor could also buy, and build the part a customer would notice if it disappeared. Authentication, billing, notifications and file storage are commodity subsystems where a vendor has already absorbed years of edge cases. Your domain logic, your data model and whatever makes the product worth switching to are the parts nobody can sell you.
Is it cheaper to build authentication yourself? Almost never, and the reason is that the build is not the expensive part. Password reset, session revocation, SSO for the first enterprise buyer, audit trails and the security review that follows a breach are all still coming, and they arrive as interruptions rather than as planned work. You are not comparing a build against a subscription, you are comparing it against a subscription plus a maintenance obligation with no end date.
When does building a commodity subsystem actually make sense? When the vendor's model genuinely does not fit yours, and you can say concretely how. A billing model with usage metering the vendor cannot express, or a data residency requirement that forbids identity leaving your database, are real reasons. Preferring your own abstraction is not, and neither is the price of the plan you are on today.
What does buying cost that the pricing page does not show? Integration time, the ceiling you hit when the vendor's model diverges from yours, and the migration if you outgrow it. The honest way to account for that is to ask what leaving would cost before you arrive, since a subsystem you can migrate away from in a fortnight is a different risk from one welded into every table you own.
Does buying components make the product less defensible? No, because nobody has ever switched SaaS products over whose authentication library was used. Defensibility comes from the part of the system your customers actually experience, and every engineering hour spent rebuilding a solved subsystem is an hour not spent on that part.
What this is really a decision about
Every hour spent on a solved subsystem is an hour not spent on the reason anybody would buy your product, and at seed stage you do not have enough hours to be wrong about this more than once or twice. That is the whole argument. It is not that building is bad engineering, it is that building the wrong things is the most expensive form of good engineering there is.
Deciding what deliberately does not get built is the same judgement I described in why startups should hire a Fractional CTO, and it is the work rather than a side effect of it. When the decisions go the other way and you do build, getting the monorepo right from day one is what keeps the part you did build cheap to change, and tenant isolation your database enforces is the one piece of plumbing worth owning properly, because it is the piece an enterprise buyer will ask you to prove. If you are weighing what this kind of judgement costs to rent rather than hire, that arithmetic is in what a fractional CTO costs.
Anyway, that is the shortest useful version of an argument I have had roughly forty times, and the eight-item list above is the version I actually use on a call, so feel free to steal it and skip the conversation.
⚡ Stop Rebuilding Solved Problems
Your team is three months into a subsystem your competitors bought in an afternoon. That is a quarter of roadmap you do not get back, and it usually shows up as a launch date nobody wants to say out loud.
At esence.io, I step in as your Fractional CTO to audit what you are building, name what should have been bought, and put the engineering back on the part customers actually pay for.