Claude Sonnet 5.5 Just Tilted Build vs. Buy for Internal Tools

Build vs. buy for internal tools now comes down to one question: does the workflow differentiate your business, or is it generic enough that a model can build it from a prompt this afternoon? For a growing share of internal software, the answer has flipped from 'buy the SaaS seat' to 'build it, and staff the maintenance.'

That flip has a specific trigger. Anthropic's Claude Sonnet 5.5 scores 70.6% on Terminal-Bench 4.0, an agentic coding evaluation, up from just 10.3% for Sonnet 5.¹² It also beats its own flagship: Opus 5.5 lands at 66.4% on the same test.¹ Pricing per token hasn't moved, but Sonnet 5.5 finishes tasks in fewer tokens, so it runs 30%+ faster and costs up to 30% less per task than its predecessor.¹²

That combination, a cheaper model that writes working code on the first try far more often, is why build vs. buy has moved from IT strategy decks into ordinary team Slack channels.

The moment the math flipped

Until recently, 'build it ourselves' meant a developer-week or two, a backlog ticket, and a real chance the first pass didn't work. Sonnet 5.5's jump on Terminal-Bench isn't a marginal improvement, it's a step change in how often an agent can go from a plain-English request to a working app without a human rewriting the output. Terminal-Bench 4.0 measures exactly that: can the model act inside a real environment and finish the job, not just answer a question about it.¹

The practical result shows up on platforms like Netlify, where new apps were being deployed roughly once every 10 seconds, most of them built by non-engineers using tools like Bolt and Cursor for internal use: employee survey tools, CPQ-style pricing calculators, interview-training apps.³ None of that is customer-facing software. It's the long tail of internal tooling that used to justify a $50-to-$500-a-month SaaS line item, exactly the category our look at how frontier frontend models are killing niche SaaS dashboards tracks.

What does the data actually say about build vs. buy in AI?

Here the picture gets more interesting: two credible surveys point in opposite directions, and both are right.

McKinsey's 2026 State of AI survey, based on 1,719 respondents across 97 countries, found that 32% of organizations have already decided against buying a software product or feature because agentic coding tools let them build it internally. That number rises to 41% among technology companies and closer to half among the firms McKinsey classifies as 'AI high performers.'⁴

Menlo Ventures' 2025 enterprise AI survey found the reverse trend at the application layer: 76% of enterprise AI use cases are now purchased rather than built, a sharp swing from the near-even 47/53 build/buy split in 2024.⁵

Both are true because they're measuring different layers of the stack:

• Foundational AI applications (chat assistants, copilots, model access) are increasingly bought, because building a competitive LLM product from scratch is a different order of problem than most companies want to own.⁵
• Narrow internal workflow tools (dashboards, intake forms, pricing calculators, status pages) are increasingly built, because a coding agent can now produce a working version faster than procurement can process a vendor contract.⁴

The McKinsey survey also carries a caution worth sitting with: only 37% of organizations attribute any EBIT impact to AI, and just 6% qualify as 'AI high performers,' flat year over year, even though 80% of individuals report personal productivity gains.⁴ Build decisions are outrunning proof that they pay off. That gap is exactly where governance discipline needs to sit, and we'll come back to it.

Why niche B2B SaaS is the most exposed category

The SaaS products getting replaced first aren't the systems of record. They're the narrow, workflow-specific tools that were always thin wrappers around a form, a spreadsheet, and a notification. A Netlify revenue-ops staffer built a pricing calculator that could displace a category of software known as CPQ, using Bolt in an afternoon.³

That pressure shows up in public markets too. AlixPartners flagged more than 100 publicly listed midmarket enterprise software companies (under $10 billion in revenue) getting squeezed from both directions: AI-native entrants replicating their core functionality cheaply, and the big platforms folding equivalent features into suites customers already pay for.⁶ High-growth companies in that cohort dropped from 57% in 2023 toward the high 30s the following year, and median net-dollar-retention slid from 120% in 2021 to 108% by late 2024.⁶ If your SaaS bill is for a tool that does one narrow thing well, that vendor is the one feeling this first. Our breakdown of how AI coding changed the build-vs-buy math goes deeper into where that threshold sits.

What does an internal tool actually cost to build versus buy?

The sticker price of SaaS sprawl keeps climbing even as building gets cheaper. Average SaaS spend hit $4,830 per employee in 2025, up 21.9% year over year, and organizations waste an average of $21 million annually on licenses nobody's using. Against that backdrop, 'just build it' sounds less like bravado and more like arithmetic.

But the honest comparison has to include the part everyone skips: maintenance. Reflex's 2026 build-vs-buy framework estimates ongoing maintenance runs two to four times the original build cost. Because AI has compressed the upfront build cost so much, maintenance now makes up an even larger share of a tool's lifetime cost than it used to, illustratively rising from around 71% of total cost pre-AI to closer to 89% today.⁷

The framework's worked example is useful because it's concrete: a custom-built internal MRP tool for 40 to 100 users runs $165,000 over five years, against $244,000 for the equivalent SaaS purchase, with the cost lines crossing somewhere between year two and year three as user counts and licensing tiers climb.⁷ Build wins on total cost, but only if someone is budgeted, named, and accountable for that maintenance tail from day one. Our practitioner's guide to building internal tools with AI covers what that ownership actually looks like week to week.

Where buying still wins

None of this argues for building everything. A framework circulating around Claude Code adoption puts it plainly: build only when two conditions hold at once, no good off-the-shelf solution exists, and the capability genuinely differentiates the business.⁸ Outside that intersection, buying is usually still the right call.

That holds especially for:

• Systems of record. Payroll, accounting, and identity infrastructure carry compliance and audit requirements that a custom build inherits as a liability, not a feature.
• Commodity infrastructure. Email delivery, payments processing, and similar plumbing are solved problems where a vendor's scale and reliability beat anything you'd build.
• Anything where speed to value matters more than five-year cost. If a team needs a working tool this week and the SaaS option is one signature away, the maintenance-tail math doesn't matter yet.
• Tools with real regulatory exposure. A custom build means you own every compliance gap the vendor would otherwise have covered contractually.

Our four-question framework for deciding what to build, prototype, or buy walks through how to sort a given tool into one of those buckets before a single line of code gets written.

The governance bill nobody's pricing in

Here's the part that gets skipped in the excitement over cheaper builds: every custom tool an employee spins up outside IT's normal process is a new thing IT has to secure, patch, and eventually replace when that employee leaves.

The visibility gap is already wide. Ninety-two percent of IT leaders believe they have full visibility into the AI tools running in their environment, yet 71% of the same group acknowledge unapproved AI use is already common.⁹ Eighty-six percent report at least one negative incident tied to unapproved AI use in the past year, even though 79% say shadow AI is genuinely boosting productivity.⁹ Those two facts sitting side by side are the whole problem: the tools work, and nobody official knows they exist.

That's where treating internal software as an owned asset, not a rented convenience and not a rogue Slack-bot experiment, starts to matter. Platforms like Remy exist precisely to give IT a real inventory of what's been built, where it lives, and who's responsible for it, which is the missing piece in most 'build it ourselves' success stories.

A decision rule for 2026

Strip the noise and the decision reduces to four checks, run in order:

1. Does this differentiate us? If yes, and no off-the-shelf tool fits, build it and staff it properly.
2. Does it touch compliance, payroll, or identity? If yes, buy, regardless of what a coding agent could produce.
3. What's the five-year cost, maintenance included? Run Reflex's math, not just the build estimate.⁷
4. Who owns this after the person who built it moves teams? If there's no name in that box, don't ship it.

Sonnet 5.5's benchmark jump is real, and it's changing behavior fast.¹² But a model that writes good code on the first try doesn't answer who patches that code in year three. That's still a people question, and it's the one worth answering before the build button gets pressed.