Go back

Article

Jun 10, 2026

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

Most buy-vs-build articles are vendor copy in disguise. Here's the 5-year math, both directions, plus the third option nobody scores

Two black architectural slabs converging toward a single seam of orange light

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.

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.

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:

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

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.

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.

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.
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.
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.
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.

How should a small team prioritize custom software development services?

Start with the workflow that already has a baseline: hours, leads, errors, or budget waste.

What should be measured before investing in custom software development services?

Measure cycle time, volume, handoffs, error rate, and the current owner.

When should buy vs build software decision framework stay manual instead of automated?

Keep it manual when judgment, approval, brand nuance, or customer trust is on the line.

How does custom software development agency change the budget for custom software development services?

custom software development agency usually adds integration, QA, and monitoring work.

What is the first project to launch from this buy vs build software decision framework playbook?

Launch the narrowest workflow with a visible result.