How do the two cost curves actually compare?
SaaS is a subscription that grows on two axes at once: the number of seats and the vendor's annual price increase. It starts near zero and never stops.
Custom software is a large one-time cost followed by a maintenance line that is roughly flat and does not care how many people use it. The two curves cross at some point, and the entire decision is whether that point falls inside your planning horizon.
The mistake in most build-versus-buy analyses is comparing the build cost against the subscription and stopping there. A build has a maintenance cost — hosting, security patching, dependency upgrades, the statutory changes, and the person who fixes it — and leaving it out is how a five-year comparison gets won on paper and lost in practice.
| SaaS | Custom | |
|---|---|---|
| Year one | Subscription + configuration + data import | Full build cost |
| Years two to five | Subscription, escalating with seats and annual increases | Maintenance at roughly 15–20% of build, plus hosting |
| Cost driver | Seat count and time | Feature count and integration count |
| Cost of growth | Linear with headcount | Near zero until it needs new features |
| Speed to value | Days to weeks | Months |
| Who carries delivery risk | The vendor | You |
| Who carries continuity risk | You — pricing, roadmap, acquisition | You — but on your own terms |
When does custom genuinely win?
Four situations, and they are narrower than the enthusiasm around custom software suggests.
- High seat counts. A per-user subscription across several hundred users compounds into a number that a one-time build clears comfortably — this is the most common honest case for building.
- The process is the advantage. If the way you do a thing is why customers choose you, adopting a product that standardises it is paying to become more like your competitors.
- Integration is the whole job. When the real requirement is that six existing systems agree, the cost is in the integration either way — and building means you are not also paying a subscription for a UI you barely use.
- Regulatory or residency constraints the product cannot satisfy. Where the data cannot leave a jurisdiction or a network, the choice is often made for you.
When is buying obviously right?
Whenever the software is not the differentiator, buying is correct even when building is cheaper on a spreadsheet — because the spreadsheet does not price the attention.
Nobody has ever won a market because their payroll system was bespoke. Accounting, payroll, email, helpdesk, HR onboarding, and expense management are solved problems with mature products, and building any of them consumes the scarcest resource you have: the engineering attention that could have gone into the thing customers pay for.
Buying is also right when speed decides the outcome. A product live in three weeks that fits 80% of the need usually beats a perfect fit eight months later, because the 20% gap costs less than the eight months did.
What does the build-versus-buy analysis usually leave out?
Both sides of the comparison have costs that do not appear in either quote, and they are the ones that decide it.
- On the SaaS side: the price increase at renewal, per-seat costs as you grow, charges for API access or data export, the integration work to connect it to everything else, and the migration cost if the vendor is acquired or shuts the product down.
- On the custom side: maintenance, hosting, security patching, the cost of the knowledge living in a small number of heads, and the fact that a system nobody has touched for two years is not free to change — it is expensive to change.
- On both: the change-management cost. Getting staff to use a new system well is the same size of problem regardless of who wrote it, and it is routinely left off both estimates.
Is there a third option?
Usually, and it is what most mature organisations actually run.
Buy the commodity layer — accounting, payroll, email, helpdesk, storage — and build only the layer that is genuinely yours, on top of it. The build stays small, so it stays maintainable, and the subscription stays confined to the parts where a vendor's economies of scale genuinely beat yours.
This is also the structure that keeps options open. A small custom layer with clean integrations can survive replacing any one of the products underneath it. A monolithic build cannot, and neither can a business whose every process lives inside one vendor's product.