Build vs buy: the 2026 case for custom AI tools

The build vs buy AI decision has quietly flipped for a growing set of workflows. Agentic coding tools scaffold, test, and integrate custom software fast enough that owning a differentiating workflow is no longer the multi-quarter capital project it was in 2021 — which means more firms now win by building the tools they used to rent as branded SaaS.

Two things are pushing the same way at once. On the build side, the cost of writing custom software has come down — unevenly, and not to zero, but materially. On the buy side, 2026 has been a masterclass in what you give up when you rent: a frontier model switched off by a government directive overnight, SaaS repriced mid-contract as vendors layer consumption charges on subscriptions, and platforms quietly turning into agent-callable API layers you build on top of rather than finished workflows you control.

This guide is a decision framework, not a manifesto. It puts the bullish and bearish AI-productivity evidence in the same table, prices the lock-in tax honestly, gives you a matrix that scores all three paths — build, buy, and build-on-buy — and spends a full section on when branded SaaS is still the right call. It builds on our full agency-stack build-vs-buy decision framework and the enterprise build-vs-buy calculus for AI agents.

For two decades the build-vs-buy default leaned buy for almost everything below the core product. The reason was economic: custom software carried a heavy fixed cost — senior engineering time, multi-quarter timelines, and a maintenance tail that outlived the people who wrote it. Renting a branded SaaS product converted that capital project into a predictable monthly line item, and for non-differentiating work that trade was almost always correct.

Agentic coding harnesses changed the input costs. Scaffolding a service, wiring integrations, generating tests, and drafting the first working version of a workflow now takes a fraction of the engineering hours it took in 2021. That does not make custom software free — the maintenance tail is still real, and, as the evidence in the next section shows, the productivity gains are uneven. But it does lower the upfront barrier enough that the old default deserves a fresh look, especially for the workflows that actually differentiate a business.

The interesting shift is not that building got cheap enough to build everything — it didn’t. It is that building got cheap enough to make ownership and control affordable for the specific workflows where they matter. That reframes the whole decision away from a pure cost comparison and toward a question of what you are willing to hand to a vendor.

The most durable lens for this decision predates the AI era. Geoffrey Moore’s core-versus-context framing splits work into two buckets: core is the work that creates differentiation and wins customers, and context is everything you must do to stay in business but that cannot differentiate you. Moore’s rule of thumb is to keep core in-house and automate or outsource context. The twin idea comes from Amazon: Jeff Bezos popularized undifferentiated heavy lifting — backend work that adds no value to the mission. By Amazon’s own historical estimate (originating around 2006), engineers spent roughly 70% of their time on that kind of work before shared platforms freed them for customer-facing innovation.

What the AI era changes is not the framework but the weights inside it. When building was expensive, plenty of core work got rented anyway because owning it was unaffordable. Now that the build cost has come down, the honest question for each workflow is the classic four-factor test: total cost of ownership, speed to value, degree of differentiation, and who carries the maintenance burden.

Almost every vendor-driven build-vs-buy article cites one number: the bullish one. The credible move is to show the full spread. Three serious studies point in different directions, and the difference is mostly about study design and tool vintage — so read them together, not in isolation.

The forward-looking point is that the METR result is already partially dated. Its tools were early-2025 assistants used inside an editor; the 2026 shift is toward agentic harnesses that run tests, iterate, and hold longer context. That does not automatically flip the result — DORA’s batch-size caution still applies, and larger AI-generated changesets genuinely add delivery risk — but it does mean the build-side cost curve is still moving down, not settling. Plan for a world where building a differentiating workflow keeps getting cheaper and buying a rented one keeps getting more expensive.

The rented option looks cheap on the invoice and expensive on the way out. Trade-press data from 2026 sketches the shape of the tax. According to SaaS Mag, 2,698 SaaS M&A transactions closed in 2025, up 28% year over year — the highest annual count recorded — with consolidation underwritten partly by an estimated $3.7 trillion in private-equity dry powder seeking deployment. Zylo reports that 68% of tech leaders plan vendor consolidation in 2026, most targeting around 20% fewer providers, and that the average enterprise carries roughly $21 million a year in SaaS license waste. Every one of those figures is a trade-press aggregate, not our own measurement — treat them as directional.

The price line is moving the same way. Zylo attributes an approximately 8% single-year rise in SaaS spend to vendors monetizing AI features, restructuring tiers, and layering consumption charges on top of subscriptions. Its 2023-baseline examples of list-price increases are worth seeing side by side.

The waste and the price hikes are only half the tax. The other half is switching cost. One trade-press analysis (Gain) reports that organizations trapped in vendor lock-in face switching costs around 16 times higher than those that planned for portability, and that a majority of enterprises say they worry about lock-in. Whatever the exact multiple, the direction is not in dispute: the cost of leaving a platform is real, it compounds, and it almost never appears on the first-year business case. This is the concrete mechanism behind the SaaSpocalypse thesis — as agents make it cheaper to rebuild rented workflows, the switching-cost moat that protected SaaS incumbents gets thinner.

When a workflow depends on a single external model or SaaS product, three levers you don’t control can move without warning: availability, price, and the API surface itself. 2026 handed each lever a public demonstration. Use them as illustration, not as a claim that any one vendor is uniquely risky — the point is structural.

The availability lever is the one that stopped being hypothetical this year. A frontier model was disabled by a government directive and then reinstated weeks later — a reversible episode, but proof that the off-switch exists and sits outside your control. We cover the export-control episode in full separately; here it matters only as evidence that owning the orchestration and data lets you swap the model underneath when a supplier moves.

The API-surface lever is subtler and, for most teams, more consequential. When a CRM exposes an MCP server for AI agents and a competitor rebuilds its whole channel around agent delivery — see Salesforce’s partner-program overhaul for the agentic era — the platform you rent is increasingly a programmable substrate, not a finished workflow. That is genuinely useful, but it quietly moves the differentiating logic from the vendor’s product into whatever you build on top. The mature response is to keep an open-weight second source behind a gateway so no single supplier owns the on-ramp.

Most build-vs-buy content forces a binary. The useful version scores three paths — custom-build (own), branded SaaS (rent), and build-on-buy (hybrid) — against the dimensions that actually decide the outcome. Read each row as a question about your specific workflow, not as a verdict on software in general. The pattern that emerges: buy for context and speed, build for differentiation and control, and reach for hybrid when you want both.

The matrix is deliberately not scored as a single number, because the right answer is per-workflow. A payroll system and a proprietary pricing engine sit at opposite ends of the differentiation row and should be decided differently even inside the same company. The one structural bias worth naming: the continuity row has quietly become the tiebreaker, because 2026 turned availability, price, and API surface from abstractions into dated events.

Owning is not automatically cheaper, and it is worth saying so plainly. The sketch below is an illustrative three-year total-cost-of-ownership model for a mid-size team automating one core workflow — assume 25 seats and a 36-month horizon. These are not measured benchmarks; they are a worked example with stated assumptions so you can substitute your own seat count, rates, and horizon. Every column total is the arithmetic sum of the lines above it.

Read the totals honestly. In this worked example the custom build runs about 5% more than the rented SaaS over three years, while the hybrid path lands roughly 6% under it. The headline is not the small dollar gap — swap in your own rates and it can invert either way. The headline is that owning costs about the same as renting in this scenario and buys you the continuity the rented column cannot: your data, your roadmap, and the freedom to swap the model underneath. That is the trade the invoice never shows.

Because the dollar gap is small and the control gap is large, the deciding factor is rarely the total — it is what the workflow is worth to you if a supplier changes the terms. That is exactly the analysis we run inside our AI transformation practice: model the TCO honestly on your numbers, then weigh it against the continuity you are handing over.

This is not an anti-SaaS argument. For a large share of the software a business runs, buying is the correct, senior-level call — and treating build as a default is its own kind of waste. Four situations tilt hard toward renting.

The pragmatic third path deserves the last word: build-on-buy. Own the orchestration, the agent logic, and the data model; rent the commodity substrate — the model API behind a gateway, auth, payments, certified-compliance building blocks. That is precisely what platforms-as-programmable-substrates now enables, and it is how we approach custom CRM automation: keep the differentiating workflow and the customer data in something the client owns outright, while renting the undifferentiated plumbing underneath. The flagship pattern in our own work is an internal operations app the client owns end to end — differentiating logic in the house, commodity services rented behind it.