Buy vs Build Software: The 5-Year Math Most Comparisons Skip

Most buy-vs-build articles are written by people selling one of the two answers. This one isn't. We'll run the actual numbers in both directions, then score the option almost nobody writes about: a thin custom layer over commodity APIs.

The short version of the buy vs build software decision framework: if the system is plumbing, buy it. If it's the thing customers pay you for, build it. If it's somewhere in between (most internal tools are), wire commodity APIs together with a thin custom layer and stop paying per-seat for software your team half-uses. The rest of this piece is the math behind that answer, and a 15-minute decision tree you can run on a real project this week.

TL;DR

• Only 54% of SaaS licenses are actually used, per Zylo's 2026 SaaS Management Index of 40M+ licenses.

• Large custom IT projects run 45% over budget and deliver 56% less value than predicted (McKinsey/Oxford, 5,400+ projects).

• Median SaaS spend hit $9,455 per employee in 2026; wasted spend averages $19.8M at large orgs.

• Expert-supervised AI builds at $25K–75K have collapsed the cost floor that made "buy" the default answer.

• The right question isn't buy or build. It's: is this differentiation, or is this plumbing?

1. The question behind the question: differentiation or plumbing?

Buy-vs-build is the wrong frame. The real question is whether the software is differentiation (the reason a customer chooses you over a competitor) or plumbing (the reason your team can function at all).

Plumbing should be bought. Payroll, email, calendar, accounting, video calls. Nobody wins a customer because their G/L is bespoke. The vendor amortizes R&D across thousands of customers and you ride that curve for the price of a seat.

Differentiation should be built. If a customer pays you for a workflow, a model, a piece of judgment, or a data asset that doesn't exist anywhere else, you cannot rent it. The moment you do, your moat becomes someone else's product roadmap.

Most software a mid-market company touches is neither. It's the middle layer — the CRM bent into a project tracker, the spreadsheet that became a pricing engine, the dashboard stitched from four tools at 2am. That middle layer is where the build vs buy decision criteria actually get interesting, and it's where the third option lives.

2. The real cost of buy: per-seat creep and the 46% of licenses you don't use

The sticker price on SaaS is rarely the real cost. Two numbers from Zylo's 2026 SaaS Management Index, which analyzed more than 40 million licenses, set the floor for any honest saas vs custom software cost conversation:

• Only 54% of SaaS licenses are actually used. The other 46% are paid for and ignored.

• Median SaaS spend reached $9,455 per employee in 2026, with large organizations averaging $19.8M in annual wasted spend.

Let that sit. Nearly half of every seat line on your renewal is paying for software somebody logged into once in Q1. The buy case is still right for plumbing; it's just rarely as cheap as the sales deck implies.

Three compounding costs the comparison spreadsheets usually skip:

1. Per-seat creep. Pricing tiers escalate at exactly the headcount you hit when the tool finally matters. A $20/user tool at 25 people is a $50/user tool at 75.

2. Integration tax. Every SaaS tool that doesn't talk to your other SaaS tools generates a workflow somebody owns manually. That somebody costs more than the license.

3. Switching gravity. After year two, the data, the muscle memory, and the admin work to migrate make the vendor's next price hike effectively non-negotiable.

Net of that, "buy" is the right answer for any system where you're a median customer. It's the wrong answer the moment your use case bends sideways from what the vendor optimizes for.

3. The real cost of build: overruns, maintenance, and key-person risk

The honest counterweight comes from the McKinsey/Oxford study of more than 5,400 large IT projects: on average they run 45% over budget and deliver 56% less value than predicted.

That's a brutal multiplier. A $400K build planned to deliver $1M in value becomes a $580K build delivering $440K. The ROI flips negative before the second sprint demo.

Three failure modes drive most of that overrun in our client work:

• Scope you didn't price. Auth, audit logs, role permissions, environments, monitoring, on-call rotation. None of it shows up in the original quote. All of it ships.

• Maintenance debt. A custom system at rest still costs roughly 15–25% of its build cost per year to keep alive (rough industry rule, varies by stack). That number is invisible in year-one decisions and load-bearing by year three.

• Key-person risk. The contractor or staff engineer who wrote it leaves. The system is now a black box with a beating heart.

The build case is right when the system is differentiation, when the workflow is genuinely yours, or when you've already paid the SaaS tax for three years and have the data to prove the vendor will never bend to fit you. The build case is wrong as a default.

4. The 5-year TCO worksheet (copy it)

Most build vs buy software analysis stops at year-one cost. The decision lives at year five. Here's the worksheet we run with clients — copy it into a sheet and fill in your numbers.

Buy side (per year, then × 5):

• License cost × projected headcount, escalated 12–18% per year for tier creep (use your vendor's actual pricing page; see its published pricing page for benchmarks)

• Implementation and onboarding (year 1 only, typically 20–40% of year-one license)

• Integration work to connect to your other systems

• Admin time: roughly 0.25–0.5 FTE for any tool above 50 seats

• Switching cost in year 5 if you migrate (data export, retraining, parallel run)

Build side (one-time + per year):

• Build cost (expert-supervised AI builds now land at $25K–75K for focused internal tools, per Chrono Innovation's 2026 cost reference; larger systems scale from there)

• 45% overrun buffer if the project is large or cross-functional (McKinsey baseline)

• Maintenance at ~15–25% of build cost per year

• Hosting, monitoring, security tooling

• Key-person succession: budget for a second engineer to know the system

Run both columns to year five. The answer is almost never close. When it is close, you've found the third option.

Run this on one system on your stack this week. If you can't answer the maintenance question, it's already answered.

5. The third option: thin custom glue over commodity tools

The option nobody scores: buy the commodity primitives, build the thin layer that makes them yours.

A modern stack lets you treat OpenAI, Stripe, Twilio, Postgres, Auth0, and a half-dozen vendor APIs as Lego bricks. The custom code is the orchestration on top — the workflow, the decision rules, the UI your team actually uses. You're not building a CRM. You're building the 300 lines of logic that make a CRM behave like your CRM.

Why this works now in a way it didn't five years ago:

• The commodity layer is genuinely commoditized. Auth, payments, messaging, storage, and LLM inference are one API call away.

• Expert-supervised AI builds in the $25K–75K range can produce production-grade internal tools in 4–8 weeks, where the equivalent custom project in 2019 was a 9-month engagement.

• You keep the vendor's R&D dividend on the plumbing while owning the layer that actually differentiates.

The failure mode here is real: thin-glue systems become spaghetti if nobody owns the contract between layers. That's a decision-rights problem, not a technology problem, and it's the same discipline that makes any internal tool ROI hold up past year two. We cover the operating side of this in our software development practice.

6. A decision tree you can run in 15 minutes

Four questions, in order. Don't skip ahead.

1. Is this differentiation or plumbing? If a customer would pay more because of how this works, it's differentiation. Build it, or build the layer that makes it yours.

2. How integration-heavy is the workflow? If the value lives in connecting three or more existing systems, no single SaaS tool will fit. That's hybrid-glue territory.

3. How will seat count grow over 3 years? If you'll cross a pricing tier that triples cost-per-seat, the buy math collapses faster than people expect.

4. Do you have, or can you hire, the team to maintain it? If the answer is no and you can't budget a second engineer to own succession, buy it even if the math says build.

If you can't answer #4 with a real name and a real budget line, the decision is made for you. A few commodity AI tools wired together will outperform a custom system nobody owns.

7. Three worked scenarios: CRM, internal dashboard, customer portal

Scenario A: CRM for a 40-person services firm. Buy. HubSpot, Pipedrive, or Salesforce all amortize their R&D across a category you are a median customer in. The differentiation lives in how your team uses it, not in the CRM itself. Budget the admin FTE honestly and audit license utilization quarterly against Zylo's 54% baseline.

Scenario B: Internal ops dashboard pulling from 5 systems. Hybrid glue. No SaaS tool will ever fit because the value is the specific shape of your five systems. A thin custom layer — auth via Auth0, data via your warehouse, UI in whatever framework your team knows — lands in the $25K–75K range and ships in 6–10 weeks. Buying a BI tool here means paying per-seat forever for 60% of what you need.

Scenario C: Customer-facing portal that's part of your product. Build. This is differentiation. The customer is paying for it. Renting it from a vendor means your product roadmap is now their product roadmap, and your switching cost grows every quarter. Run the McKinsey 45% overrun buffer honestly in the budget and assign succession from day one.

FAQ

When is buying SaaS clearly the right answer?
When the system is plumbing (payroll, email, accounting, video), when you're a median customer for that category, and when seat growth is predictable. The vendor's R&D dividend is real, and no internal team will out-build a focused SaaS company on its core product at reasonable cost.

What's the biggest hidden cost of building custom software?
Maintenance and key-person risk, not the initial build. A custom system typically costs 15–25% of its build price per year to keep alive, and McKinsey's study of 5,400+ projects found large builds run 45% over budget on average. The year-one number is almost never the real number.

How do I know if a workflow is differentiation or plumbing?
Ask whether a customer would pay more, or choose you over a competitor, because of how this specific workflow works. If yes, it's differentiation and you should own it. If the workflow is invisible to customers and identical to what every peer company runs, it's plumbing — buy it.

What does "thin custom glue" actually look like in practice?
Around 200–2,000 lines of code that orchestrate commodity APIs (auth, payments, LLM inference, storage, messaging) into a workflow specific to your business. You own the logic and the UI; the vendors own the primitives. Expert-supervised AI builds at $25K–75K make this approach viable for projects that would have cost 5x in 2019.

How often should we re-run the buy vs build software decision framework?
Annually for each significant system, and any time a vendor announces a pricing change, a seat count milestone is crossed, or a workflow gets re-scoped. The Zylo data showing 46% of licenses go unused suggests most companies haven't audited their buy decisions in years.

Pick one system on your stack this week. Run the 5-year worksheet honestly, both columns. If the numbers say something different than your gut, the numbers are usually right. When you want a second set of eyes on the math, send us the worksheet.