Build vs. Buy Just Flipped. Most Teams Haven't Noticed Yet.

The Decision You’ve Been Making on Autopilot

Every AWS practitioner has a version of this conversation at least once a quarter. Someone on the team suggests building something custom. Someone else points out there’s a managed service or SaaS product that does it already. The room does the mental maths: engineering time, ongoing maintenance, opportunity cost. Nine times out of ten, you buy.

That calculus made sense for twenty years. I’m not sure it makes sense anymore.

What Changed

The short version: the cost of building software is collapsing. Not gradually. Not theoretically. Right now.

If you’ve been following the fallout from what Jefferies’ trading desk coined the “SaaSpocalypse,” you’ve seen the headlines. Anthropic released 11 open-source plugins for Claude Cowork targeting legal, finance, and data analytics verticals. Within hours, $285 billion was wiped from the Nasdaq Cloud Index. Thomson Reuters down 17%. RELX down 16%. LegalZoom down 20%. The S&P North American Software Index had already declined 15% in January alone, its worst month since October 2008. Then Palantir’s CEO went on an earnings call and articulated a thesis that AI isn’t augmenting enterprise software, it’s replacing it. The market repriced an entire industry in a week.

The hot takes focused on whether AI will “kill SaaS.” That’s the wrong question. The interesting question for people who actually build things on AWS is simpler: when does it become cheaper to build a custom tool than to keep paying per-seat for the general-purpose version?

That threshold is moving fast. And for certain workloads, it’s already crossed.

The Old Maths

The traditional build vs. buy calculation was brutal and predictable:

Buy: $50/seat/month, works out of the box, vendor handles updates, security patches, compliance. You’re up and running in a week.

Build: 3-6 months of engineering time, ongoing maintenance burden, security responsibility, no SLA to fall back on when it breaks at 2 AM before a board meeting. Your best engineers are maintaining plumbing instead of building product.

The answer was almost always buy. Not because the SaaS product was perfect, but because the alternative was worse. Building was expensive and slow. Maintaining was expensive and relentless. The opportunity cost of tying up your engineers on internal tooling was the real killer.

That calculation rested on one assumption: software engineering is expensive and slow.

The New Maths

Here’s where it gets uncomfortable for anyone selling per-seat licences.

AI coding assistants are operational systems now, not demos. A quarter of Y Combinator’s Winter 2025 batch had codebases that were 95% AI-generated, with companies reaching $10M revenue on teams under 10 people. Satya Nadella told LlamaCon that 20-30% of Microsoft’s code is now AI-generated. Google reported the same trajectory. StrongDM published a Software Factory framework with two charter rules: code must not be written by humans, and code must not be reviewed by humans. Stanford Law published a response paper the same week asking “trusted by whom?” The fact that this is even a serious academic debate tells you where we are.

Apply that to the build vs. buy decision:

Buy: Still $50/seat/month. Still general-purpose. Still designed to serve every company on Earth, which means it’s optimised for nobody in particular. Still charging you per human who touches it, even as AI agents start doing the touching.

Build: A weekend. Maybe less. An AI agent that understands your CDK patterns, your naming conventions, your security boundaries. Custom to your team’s actual workflow. Cost: API tokens. Ongoing maintenance: also API tokens. And the thing it builds is shaped around how your team actually works, not how a product manager in San Francisco imagined you might work.

I’m not saying the SaaS product is suddenly worthless. I’m saying the gap between “good enough custom” and “paying for general-purpose” has narrowed to the point where the old default answer needs questioning.

Where Build Wins (Right Now)

Let me be specific about where I think the maths already favours building, because it’s not everywhere.

Internal tooling. Dashboards, reporting tools, admin interfaces, workflow automations. These are the bread and butter of SaaS spend in most organisations, and they’re the easiest things for AI to build well. You know the requirements. The audience is internal. The stakes are lower. If you’re paying per-seat for an internal dashboard that an AI agent could build and maintain for you, you’re overpaying.

Glue code and integrations. The custom middleware that connects your CRM to your billing system to your support platform. Traditionally this was either expensive custom development or an iPaaS product with its own per-seat fees. An AI agent can build, test, and maintain these integrations for a fraction of the cost.

Domain-specific workflows. If your team has a process that doesn’t map cleanly to any off-the-shelf product, you’ve been paying for a general-purpose tool and working around its limitations. Those workarounds are now more expensive than just building the thing you actually need.

Where Buy Still Wins

Here’s the honest assessment, because the “build everything” crowd is getting ahead of themselves.

Proprietary data systems. Thomson Reuters’ case law database isn’t something you replicate over a weekend. Salesforce’s customer graph is irreplaceable. The data underneath enterprise SaaS is a genuine moat. An AI can build a frontend, but it can’t conjure decades of structured proprietary data out of thin air.

The single wringable neck. Enterprises buy Salesforce not because it’s the best possible CRM. They buy it because when something breaks at 2 AM, there’s a phone number to call and a contract that says someone is accountable. That accountability layer, the vendor relationship, the SLA, the legal liability, is enormously valuable. No amount of AI eliminates the need for it. If anything, AI-driven complexity makes it more important.

Regulated environments. If you’re in financial services, healthcare, or government, the compliance burden of running custom software is real and heavy. A SaaS vendor absorbs that burden for you. Building custom means owning that compliance yourself. For some organisations, that trade-off still favours buy.

The Klarna warning. This one is worth paying attention to. Klarna’s CEO famously claimed they’d shut down Salesforce and Workday, replacing them with AI. The headlines were enormous. Then he walked it back, saying he was “tremendously embarrassed” by how the narrative spiralled. They’d replaced Workday with Deel (another SaaS product), not an LLM. Their AI customer service initially looked brilliant, handling the work of 700 agents. Then they reversed course and started hiring humans again after customer satisfaction dropped. Impressive initial metrics followed by real-world complications. That pattern keeps repeating.

The articulation problem. This is the one that doesn’t get enough airtime. When your VP says “I need a better pipeline tracker,” that sentence contains about 5% of the information needed to build a useful tool. The other 95% is buried in how the team actually works, what the unspoken conventions are, which exceptions matter. Getting AI to extract that implicit knowledge is the hardest problem in the stack. It’s improving fast, but it’s not solved.

The KPMG Playbook (Use This Tomorrow)

Even if you’re not ready to build, the shift in economics gives you immediate leverage.

While everyone was watching stock prices, KPMG quietly pressured their auditor, Grant Thornton, to cut fees. As reported by the Financial Times, KPMG’s CFO Michaela Peisger made the argument that AI and new technology should make audits more efficient. Grant Thornton blinked. KPMG’s audit bill dropped from $416,000 to $357,000, a 14% reduction. Going Concern called it “a Pandora’s box filled with stingy clients.”

That playbook works at every scale. Your Salesforce rep, your monitoring vendor, your log management provider. They know the economics are shifting. They’re expecting the call.

The numbers back this up. Seat-based pricing dropped from 21% to 15% of SaaS companies in just twelve months. Credit-based models surged 126%. There were over 1,800 pricing changes across the top 500 SaaS companies in 2025 alone. Even Salesforce pivoted its Agentforce pricing three times in under a year, going from consumption-based to credits to, ironically, back to per-seat. The vendors are scrambling. Use that.

You don’t need to threaten to replace them with AI. You just need to point at the landscape and say: “We both know the world changed. Let’s talk about rates.”

The Practical Framework

Here’s how I’m thinking about build vs. buy decisions now:

Default to buy when:

• The vendor has proprietary data you can’t replicate
• Compliance and accountability matter more than customisation
• The articulation problem is hard (you can’t clearly specify what you need)
• The domain is complex and the vendor has deep expertise

Default to build when:

• It’s internal tooling with a known audience
• You’re paying for a general-purpose tool but only using 20% of it
• The tool is mostly glue code or integrations
• Your team’s workflow doesn’t map to any off-the-shelf product
• Per-seat costs are scaling faster than value delivered

Always negotiate when:

• You’re renewing any SaaS contract in 2026

The Bigger Picture

The build vs. buy calculation isn’t just a procurement decision anymore. It’s an architectural decision about how your team works.

If you keep defaulting to buy for everything, you end up with a stack of general-purpose tools that each solve 60% of your problem, connected by brittle integrations, all charging per seat. The average organisation now spends $55.7M annually across 305 SaaS applications, with SaaS inflation running at 11.4% year-on-year, five times higher than general market inflation. That was the best available option when building was expensive. It’s increasingly not.

If you swing too hard toward build, you end up maintaining a portfolio of custom tools with no vendor support, no accountability layer, and an articulation problem that means the tools don’t actually do what the team needs.

The right answer is somewhere in the middle, and it’s different for every team. But the default has shifted. For the first time in twenty years, “should we just build this?” is a serious question rather than a naive one.

The maths changed. Make sure your decisions have too.

I hope someone else finds this useful.

Cheers