Most build-versus-buy models put a subscription invoice next to a build quote and stop there. That comparison is wrong in both directions. It overstates SaaS value by counting seats nobody uses, and it understates the build by ignoring maintenance, migration, and integration. Payback is real. It usually arrives later than builders promise and sooner than incumbents admit.
What does a SaaS platform actually cost over five years?
Start from published pricing rather than a remembered number. As of July 2026, HubSpot's Sales Hub pricing page listed Professional at $90 per seat per month on an annual commitment, with a one-time $1,500 onboarding fee, and Enterprise at $150 per seat per month with a $3,500 onboarding fee.
Put 40 people on Sales Hub Professional. That is $3,600 a month, $43,200 a year, and $216,000 over five years before a single renewal increase. The onboarding fee is rounding error. The seat count is not.
Now apply the number most cost models skip. Zylo's SaaS Management Index, updated February 2026, reports license utilization of 54 percent in 2025, up from 47 percent in 2024.
Zylo's sample skews enterprise and its methodology is not published, so treat that percentage as directional rather than precise. The direction is the point. If your 40 seats behave like the average, you are paying $43,200 a year for something closer to 22 seats of real work. The effective price is not $90 per seat. It is roughly $165.
That is the first correction to the model, and it favors the build. It is also the correction nobody makes, because the invoice says $90.
Which costs get forgotten on the build side?
Four, reliably. Three of them are visible in the best-documented rent-versus-own case in public.
37signals is not a SaaS-versus-custom decision. It is infrastructure. But it is the same payback question with real numbers attached, published by the company that lived it, which makes it worth more than a hundred vendor calculators.
Operations headcount. In January 2023, 37signals published its 2022 cloud bill in full: $3,201,564 for the year, or $266,797 a month, already negotiated and optimized. In December 2023, David Heinemeier Hansson's cloud exit FAQ put the replacement hardware at roughly $600,000 of Dell servers (4,000 vCPUs, 7,680GB of RAM, 384TB of NVMe), projected $7 million of savings over five years, and reported $1 million already realized by September 2023. The company later raised the five-year estimate to about $10 million.
The most useful line in that FAQ is not a number. Asked whether owning the hardware meant hiring more operations staff, Hansson wrote that they "didn't change the team composition after our cloud exit." Same people, different bill. Most build-versus-buy models assume the opposite by default, and that assumption is usually the single largest line in the build column.
Migration. In January 2026, 37signals principal programmer Jeremy Daer published the writeup of moving roughly 10 petabytes and about five billion objects off S3. The transfer itself ran in under 10 days with no downtime. Getting there took a negotiated 90-day egress window and custom tooling, built because AWS's own transfer service would have cost tens to hundreds of thousands of dollars.
Read that as a warning about the direction you are not planning to travel. Leaving a platform is an engineering project with its own vendor negotiation and its own bill. If your data is inside a SaaS product today, the exit cost is already on your balance sheet. You just have not been invoiced yet.
Integration. A custom build rarely replaces one tool. It sits between several, and every connection is a permanent maintenance surface. Each vendor API you depend on will change on the vendor's schedule, not yours. This is the cost that does not appear in a build quote because it is not a feature, it is a subscription to somebody else's roadmap.
Opportunity cost. The build column should be priced in engineering months you cannot spend elsewhere, not in dollars. If the same team is the only team who can ship your product, a nine-month internal tool has a price that no spreadsheet captures.
When does the crossover actually happen?
The honest answer is that the crossover is a curve, not a date, and three things move it.
- Seat growth. SaaS cost scales with headcount. A custom build's cost mostly does not. A workflow used by 8 people almost never justifies a build. The same workflow at 80 people often does, and nothing about the software changed. Only the multiplier did.
- Renewal trajectory. The five-year SaaS number is never the list price times five. Model the increase you have actually been quoted, not zero.
- Utilization. If you are paying for roughly twice the seats you use, half your subscription is already a build budget that you are spending on shelfware. The crossover arrives when the annual subscription plus the workaround labor exceeds the annualized build cost plus its maintenance, over the period you can honestly forecast. For most mid-market workflows, that period is three to five years, not one, and not ten. One year flatters SaaS because it front-loads the build. Ten years flatters the build because it assumes a stable workflow, and workflows are not stable for ten years.
The test that resolves most of these arguments is simpler than the model: if the vendor doubled the price tomorrow, would you pay it? If the answer is yes, that workflow is load-bearing, and you are renting something you should probably own. If the answer is no, you would churn, and you should not be building it either.
Build the measurement before the software
The costs above share one property. They are all knowable before anyone writes code, and almost nobody measures them.
Before the build-versus-buy conversation, pull three numbers: actual active seats versus purchased seats, the increase on your last renewal, and the hours per month your team spends working around the tool. The third one is the one that decides it. A tool that costs $43,200 a year and consumes 20 hours a month of manual reconciliation is not a $43,200 tool.
This is the same discipline behind Commerce Beacon's SaaS platform development work: price the current process honestly before proposing to replace it. The decision framework for which side of the line a workflow falls on is covered separately in custom software or more SaaS tools. This article is the arithmetic underneath that decision.
Often the answer is neither a full build nor another subscription. It is a thin layer that removes the workaround labor while the SaaS products stay. Local Living is an example of the opposite case, where vendor onboarding, ordering, fulfillment, and admin review all belonged in one owned system because the workflow was the product. Deciding which case you are in is what virtual IT management and consulting is for, and it is a cheaper conversation than either mistake.
A platform pays for itself when the workflow it owns is worth more than the seats it charges for. That is a measurement problem long before it is a budget problem.
Common questions
Does a price increase at renewal justify building?
Rarely on its own. A single increase is a negotiation, not a signal. What justifies a build is a workflow that keeps growing in seat count while your leverage stays flat. Price increases are the symptom. Dependency is the condition.
Is the build cheaper if we use AI to write it?
Assume it lowers the build cost and changes nothing else. Maintenance, migration, integration, and opportunity cost are all still there, and they are the majority of the five-year number. Cheaper code does not make an unowned workflow cheaper to operate.