Every build-vs-buy conversation I have eventually gets to the same question: what does this actually cost over time? Not the number on the pricing page — the real number, three years out, once you count everything the pricing page doesn’t show you. That’s the calculation this piece walks through.
Why Purchase Price Is the Wrong Comparison
When a business compares a SaaS subscription to a custom build, the instinct is to compare what each costs to get started. The SaaS tool looks cheap — a few hundred dollars a month. The custom build looks expensive — tens of thousands up front. On that comparison, buying wins almost every time, and for a lot of businesses that’s the right call. But purchase price is a snapshot, and software costs accrue over years, not months. The comparison that actually matters is total cost of ownership across a realistic horizon, and three years is long enough to expose the pattern without being so far out that the numbers are pure speculation.
What the Buy Side Really Costs
Start with license fees, but don’t stop there. Most SaaS platforms tier pricing by seats, contacts, or usage volume, and growing businesses get pushed up a tier faster than they expect. A CRM that looked like $200 a month at signup is often $600–$900 a month two years later once you’ve added users and hit contact thresholds.
Then add configuration. Off-the-shelf platforms are built for a general case, and almost no business fits the general case exactly. Custom fields, workflow automation, third-party integrations via Zapier or Make, and CMS or portal setup all cost money — either your own team’s time or a consultant’s invoice. I’ve seen this line item alone run $30,000 or more over a couple of years on a platform like HubSpot.
The line item nobody puts in a spreadsheet is workaround cost. This is the staff time spent manually doing what the software should do — re-entering data between systems that don’t talk to each other, building spreadsheets to cover reporting gaps, chasing down information the tool won’t surface. It’s real cost, it’s recurring, and it’s almost always underestimated because it’s distributed across a team rather than showing up on one invoice.
Finally, factor in the cost of re-platforming if you eventually outgrow the tool anyway. Migrating years of data and rebuilding workflows in a new platform is expensive and disruptive, and it happens more often than vendors like to admit.
What the Build Side Really Costs
Custom software has its own full accounting. The initial development cost is the obvious one — discovery, design, and build, typically running 3–6 months for a substantive project. Hosting and infrastructure add a modest ongoing cost, usually far smaller than most owners expect. Maintenance is the line item to budget carefully: a reasonable rule of thumb is 15–20% of the original build cost per year, covering bug fixes, security patching, and small feature additions as your business changes.
What custom software doesn’t have is a rising per-seat or per-contact fee. Once it’s built, adding users doesn’t trigger a pricing tier change. That’s one of the more underappreciated advantages of owning your own system rather than renting one.
Where the Lines Actually Cross
On paper, a lot of owners assume the crossover point — where cumulative buy-side cost exceeds cumulative build-side cost — sits somewhere around year four or five. In the projects I’ve scoped, it’s often much earlier, sometimes inside 18 months, because the workaround and configuration costs on the buy side were invisible until someone actually added them up. That’s the exercise I’d encourage before any build-vs-buy decision: sit down and tally what the current tool is actually costing you today, including staff time, not just the invoice.
I go through the broader framework for making that call, including the three conditions that need to be true before building makes sense at all, in Build vs Buy: When Custom Software Is Worth It.
A Practical Way to Run the Numbers
If you want to do this exercise yourself, start with three columns: license and platform fees, configuration and consultant spend, and estimated workaround hours multiplied by a reasonable hourly rate for the staff doing the workaround. Add those up for the trailing 12 months, then project forward three years accounting for growth. Compare that total to a development quote plus three years of maintenance at 15–20% annually. The result is rarely as close as people expect — it usually points clearly one direction once workaround cost is included honestly.
This exercise also tends to reveal whether you’re actually ready to build, independent of cost. If you can’t quantify the workaround cost with any confidence, that’s often a sign your workflow itself isn’t stable enough yet to build custom software against — a point I cover in more depth in the main build vs. buy piece.
Don’t Skip the Staged Approach
I rarely recommend jumping straight from a TCO spreadsheet to a development contract. The strategy that works better in practice is staged: keep the packaged tool long enough to find its real limits, quantify them the way this piece describes, and then decide. I lay out that staged approach, including how to know when you’ve reached the end of what buying can do for you, in Buy Then Build: A Staged Strategy for Software Decisions.
The honest answer for most businesses running this math for the first time is that they’re not yet at the crossover point — and that’s a useful thing to know, because it means the frustration they’re feeling is a configuration problem to fix, not a build decision to make.
A Few Numbers I’ve Actually Seen
To make this less abstract: on one project, a home services business running a popular field-service platform was paying about $780 a month in licensing at their size. That looked cheap in isolation. Once we added the office manager’s roughly six hours a week spent reconciling data between the field-service tool and their accounting software, at a fully loaded cost of around $35 an hour, the workaround alone added another $900 a month. Add a part-time consultant retainer for workflow tweaks at $600 a month, and the real monthly cost was closer to $2,300 — nearly triple the sticker price. Over three years, that’s roughly $83,000, against a custom build quote for their specific field-to-office workflow that came in under $60,000 with maintenance included. That’s the kind of gap this exercise is built to surface, and it doesn’t show up if you only look at the invoice.
Not every business will find a gap that size. Plenty run the same math and find that buying is still clearly cheaper, even after counting workaround hours honestly. The point isn’t to talk yourself into a build — it’s to know which case you’re actually in before you commit real money either direction.
What to Do With the Number Once You Have It
Once you’ve run this exercise, don’t treat the output as a final verdict on its own. Cost is one leg of the decision. The other two are whether your workflow is genuinely non-standard enough that a packaged tool will never fit it well, and whether your process is stable enough that building against it now won’t lock in assumptions you’ll regret in six months. I cover both of those conditions, alongside the cost threshold, in Build vs Buy: When Custom Software Is Worth It, which is the right place to go next once you have real numbers in hand.