Book a 30-min call →
Skip to main content
Blog · 23 Sep 2025 · 10 min read

Build vs buy in 2026: the new economics

AI-paired delivery has changed the build-vs-buy math. Here's how to think about it now.

Decision workspace
TLDR audio briefing
For busy executives
~1m 12s summary · 0:00 / 1:12

The build-vs-buy heuristic that most engineering leaders learned in the 2010s went something like: “If a credible SaaS exists, buy it. The build cost (engineering time + maintenance + opportunity cost) almost always exceeds the licence.” It was good advice when it was given. It was good because the build cost was high — three to six engineers working for nine months on a CRM clone was rarely worth it.

Two things have changed since 2024 that flip the heuristic in a meaningful subset of cases.

What changed

Change 1: AI-paired delivery has compressed build cost by 3–5× on well-defined work.

The systems that were too expensive to build in 2018 — internal CRMs, custom analytics platforms, legal-AI workflows, observability stacks — are now buildable by a 2-engineer team in 8–14 weeks at a fixed price that makes board-level sense. The same systems quoted at $400K–$800K in 2018 ship at $80K–$200K in 2026.

Change 2: SaaS pricing has decoupled from cost-to-serve.

Per-seat pricing models that made sense at $50–$200/seat/mo in 2014 are now charging $800–$2,000/seat/mo for the same software class. The cost-to-serve hasn’t risen; the pricing has. The SaaS margin has expanded into the space where buyers stopped scrutinising. At enterprise scale ($500K+/yr per tool), the wrapper margin is often the largest line item.

These two changes together don’t make “build” the right answer everywhere. They do make “build” the right answer in a much wider band than it was five years ago.

The 2026 decision framework

Three primary questions, in order:

Q1: Is this a commodity or a differentiator?

  • Commodity (everyone needs it, no competitive advantage from owning it): default to buy.
  • Differentiator (your specific implementation is part of why customers buy from you): default to build.

This is unchanged from the old heuristic.

Q2: What is the annualised SaaS cost at your scale?

  • < $50K/yr: buy. Build economics rarely pencil below this.
  • $50K–$200K/yr: usually buy, occasionally build if the use case is differentiated.
  • $200K–$500K/yr: open question, run the math.
  • $500K/yr: build is increasingly the right answer, especially if the SaaS pricing is per-seat on a tool with low active-seat ratio.

The threshold has shifted down by ~3× since 2018, because build cost has fallen.

Q3: Do you have engineering capacity (in-house or via a productized firm) that can underwrite a fixed-price commitment?

  • If yes: build is a real option.
  • If no: buy, even if Q2 says build. T&M-built systems aren’t fixed-price; the cost-of-build risk is real and undermines the math.

The answer to Q3 is what determines whether the math from Q2 is a real option or a thought experiment.

Where the math has tipped most

Five categories where we’ve seen the build math overtake the buy math repeatedly in 2024–2026:

  1. Enterprise AI tools (Harvey AI, Casetext, Hebbia, Glean Enterprise). Per-seat pricing has expanded faster than underlying API costs. A custom rebuild on direct foundation-model APIs is often <10% of the licence cost.
  2. Observability (Datadog, New Relic, Splunk Enterprise). Per-host + per-log-GB pricing compounds. OpenTelemetry + open-source backends shift the cost from licence to compute, often a 10× saving at scale.
  3. CRM + sales tools (Salesforce + Outreach + Salesloft + Gong). The integrated bill at enterprise scale is staggering. A custom CRM tuned to your sales process can be a 6–9 month build that pays back in 12 months.
  4. Marketing automation (HubSpot Enterprise, Marketo, Pardot, SFMC). Same per-contact pricing dynamic. Custom rebuilds on direct providers (Resend / Postmark for email, custom event-tracking) are dramatically cheaper.
  5. Analytics + BI (Mixpanel, Amplitude, Looker). Per-event pricing on growing event volumes. Self-hosted alternatives (PostHog, Metabase) are operationally cheap once installed.

Where the math hasn’t tipped: collaboration tools (Slack, Zoom, Google Workspace), payment processing (Stripe), and cloud infrastructure (AWS, GCP). These are still buy.

How to run the math

A clean build-vs-buy memo has four sections:

  1. Current SaaS cost at observed usage, projected three years.
  2. Build cost as a fixed-price quote from a productized vendor, including 12 months of maintenance.
  3. Run cost for the build (infra, third-party APIs, ongoing engineering time).
  4. Three-year TCO for both options, with a payback period for the build.

If the payback is <12 months, build is usually right. If >24 months, buy is usually right. The 12–24 month band is where strategic factors (lock-in, differentiation, talent fit) matter most.

A vendor-neutral Strategy engagement produces this memo as a deliverable. It is the smallest, cheapest decision-support investment in the build-vs-buy stack.


Read more: /strategy/ · /upstream/ · /case-studies/

#strategy #build-vs-buy #ai-paired #decision-framework
Want this kind of work for your stack? Book a 30-min call →