Build vs. Buy for Internal Tools: How Fable 5.1 Flips the Math

Should you build or buy internal tools now that Fable 5.1 has changed the math?

Build beats buy for internal tools when a niche SaaS subscription costs more than about four weeks of a developer's time and the workflow is narrow enough for one team to own. Eighteen months ago, that was reckless advice. Today it's arithmetic.

Why was building internal tools the losing bet for so long?

For most of the last decade, building your own version of a point tool was a bad trade. A meaningful SaaS MVP took five to ten engineers, six to twelve months, and $500,000 to $1 million to reach something usable. Against that backdrop, a $50 or $200 monthly subscription wasn't worth arguing about. Buy was the default because building was expensive, slow, and risky.

That math has collapsed for one specific category: narrow, internal, non-regulated point tools. AppDirect now ships more than 90% AI-generated code across its internal development, a threshold it crossed within a year of adopting AI coding tools in earnest. The company reports a 70% reduction in development costs and in-house teams producing roughly five times the output of a traditional IT team working the old way. A basic CRM dashboard that used to take three to four months and $150,000 to $200,000 can now be built in one to two developer-weeks. One practitioner replaced a CRM subscription for 30 to 40 users with a purpose-built contacts tool in about two days.

This isn't a story about vibe-coded toys. It's a story about the marginal cost of software falling below the price of renting it, the same shift driving teams to self-host infrastructure they used to rent instead of buying it outright.

Why does Claude Fable 5.1 specifically move the needle?

Model upgrades get announced constantly and most of them don't change anyone's build-vs-buy decision. Fable 5.1 does, for one narrow but important reason: prompt caching.

Anthropic cut cache-read pricing on Fable 5.1 to $0.25 per million tokens, down from $1.00 on Fable 5. That's a 4x reduction. Input and output token prices didn't move. Fable 5.1 still costs $10 per million input tokens and $50 per million output tokens, identical to its predecessor. The saving is specific to cache reads, and that specificity matters more than it sounds like it should.

Building an internal tool with an AI coding agent isn't one prompt. It's hundreds of turns against the same repository, the same file tree, the same context window, reloaded and re-read on every step. That's exactly the workload prompt caching is built for. Anthropic estimates the price cut reduces typical workload costs by around 25%, but for highly agentic, coding-heavy sessions the reduction runs closer to 45%. Fable 5.1 isn't just cheaper. It's cheaper specifically where the meter runs longest: the long, iterative sessions that building and maintaining a real internal tool actually require, not the one-off script you throw away after running once.

That distinction is the whole argument. A cheaper one-shot completion helps you generate a snippet. A cheaper cache read helps you build and then keep maintaining a piece of software over months, which is the actual competitor to a SaaS subscription.

How much is your company wasting on unused SaaS?

Build now has a lower bar to clear because buy has gotten more expensive and more wasteful than most finance teams realize.

The average enterprise manages 291 SaaS applications today, up from 110 in 2020. Of the licenses companies pay for, 51% go unused, the highest waste rate on record, costing an estimated $18 million a year in unused software at the enterprise level. Per employee, SaaS spend now runs as high as $3,500 a year, which means a 500-person company can be burning roughly $1.75 million annually on subscriptions, with close to half of it going to seats nobody opens.

That's the baseline build has to beat, and it's a low bar. A niche internal tool doesn't need to undercut the subscription's sticker price. It needs to beat the sticker price plus the procurement overhead plus the seats nobody uses plus the renewal negotiation nobody has time for.

Is shadow AI already doing this without governance?

Here's the part that should worry IT leaders more than it currently does: this shift is already happening inside your company, informally, without anyone signing off on it.

78% of employees admit to using AI tools that were not approved by their employer. Only 7.5% have received extensive AI training, an improvement of half a percentage point over the prior year. Put those two numbers together and you get a workforce already building around sanctioned software, quietly, with no visibility into what got built, where the data went, or who maintains it once the person who built it changes teams.

One IT manager described a lead developer spending a few hours with a self-hosted coding agent to produce a proof-of-concept reporting portal that looked better and ran smoother than the enterprise tools the company had spent weeks demoing. That's not an isolated anecdote. It's the shadow-AI stat made concrete. The build shift isn't a future risk to plan for. It's a present reality to bring into the open, with real review, real ownership, and a real maintenance plan, rather than a folder of unsanctioned tools nobody in IT knows exist. That's a governance problem worth solving directly, not a reason to pretend the shift isn't happening.

When should you build an internal tool instead of buying it?

Not every SaaS line item is a build candidate. The tools worth building in-house tend to share a specific profile:

1. Cost exceeds roughly four weeks of developer time. If the annual subscription costs more than a mid-level engineer's fully loaded monthly cost, the payback period on building it is short enough to matter.
2. The workflow is narrow. One team, one process, a handful of fields and states. Not a platform trying to serve every department at once.
3. The data isn't regulated. No PII subject to strict compliance regimes, no financial reporting obligations riding on the tool's accuracy.
4. Someone owns maintenance. A team or individual with the bandwidth to patch, extend, and babysit the thing after launch, not just ship it and walk away.

This is close to the exact framework AppDirect and other practitioners describe using to greenlight build decisions. Internal dashboards, contact trackers, status pages, and reporting portals tend to clear all four bars easily, which is why they're the tools showing up first in build-it-yourself case studies. If you've ever priced out replacing a dashboard subscription with a generated frontend, you already know how quickly the math tips.

When should you still buy instead of build?

The honest version of this argument has a ceiling, and it's worth being blunt about where it sits.

Systems of record, anything touching regulated data, and genuinely complex CRM or ERP workflows remain buy categories, and the cautionary tale isn't hypothetical. Klarna replaced Salesforce with an internally built AI system, customer satisfaction declined, and the company reversed course. That's not a story about AI coding tools failing. It's a story about applying the build logic to a system that never fit the profile: broad in scope, high blast radius if something breaks, and deeply entangled with regulatory and customer-facing obligations that a lean internal team isn't resourced to carry indefinitely.

As one developer put it in a discussion of the tradeoff, buying software means the vendor now controls a part of your business's success, which is a real strategic risk, but that doesn't make buying wrong by default any more than it makes building right by default. The framework matters precisely because it tells you when to stop applying it.

What is the real strategic shift between owning and renting?

The deeper change here isn't just that building got cheaper. It's that owning software has become a defensible asset decision rather than a cost-avoidance gamble. A tool you build and control isn't a recurring line item exposed to price hikes, feature gating, or a vendor's roadmap decisions. It's an asset your team maintains on its own terms, the same logic reshaping how smaller teams now maintain what used to require a full engineering squad.

There's a second-order effect worth naming too. Once your team can credibly build the niche tool in two weeks, every SaaS renewal conversation changes shape. The vendor knows it, and so do you. The threat of building it yourself is now real leverage in a negotiation that used to run entirely on the vendor's terms, and platforms like Remy exist precisely because that leverage is worth having in-house rather than outsourcing it entirely. Fable 5.1's cache pricing didn't create this shift on its own. It just made the marginal cost of exercising that leverage cheap enough that ignoring it is now the riskier move.