The Pendulum Swings: Build vs. Buy in the Age of GenAI

When did we stop building our own software — and why does it feel like we're starting again? For most of my career, the default answer to "should we build this?" has been "probably not." Buy the platform, integrate the API, customise at the edges. Building was the expensive, slow path reserved for true differentiators. Lately though, I've been watching teams ship internal tools and workflows in days that would have been multi-month projects a few years ago. The calculus is shifting. Not everywhere, and not all at once — but the pendulum that swung hard toward "buy" over the past thirty or forty years is moving back. This post is about that arc: how we got here, what's changing, and what it means for the organisations doing the building and the platforms they might leave behind.

The Arc from Build to Buy

To understand the shift back, it helps to remember how we got to "buy" in the first place.

In the early days of computing, building was often the only option. Vendor solutions were minimal or non-existent; if you needed software, you built it. That started to change in the 1970s and 1980s. E.F. Codd's relational database concept (1970) made specialised database software far more attractive than building your own. By the 1980s, buying off-the-shelf software — dBASE, Lotus 1-2-3, Oracle's database products — had become commonplace. The efficiency gains were clear: focus on your business, not your infrastructure.

The 1990s and 2000s doubled down. ERP systems (SAP, Oracle Applications), CRM platforms, and packaged enterprise software took over. The mantra became "don't build what you can buy." Building was for edge cases; buying was for scale, support, and speed to value.

The 2010s brought the real explosion: SaaS. McKinsey's analysis of the software disruption notes that SaaS went from roughly 6% of enterprise software revenue in 2010 to 29% ($150 billion globally) by 2018. When you include companies in the middle of transitioning to SaaS, the as-a-service share reached about 75% of all enterprise software revenue. The cloud era and the pandemic accelerated the trend. Enterprises strongly favoured buying: faster deployment, no hardware, someone else's security and compliance burden.

By the late 2010s, Forrester's "buy then build" model had crystallised — buy the foundation, then selectively build customisations on top. The default had become "buy."

The Feature Bloat Problem

So why would anyone swing back toward build? Part of the answer is that "buy" started to show cracks. Not because SaaS failed, but because the way it's sold and consumed created a structural mismatch.

The statistic that keeps coming up: 70% of SaaS features go unused. Exact numbers vary by organisation, but the pattern is consistent. Enterprises adopt broad platforms and use a small set of core workflows; the rest becomes bundled overhead. You're paying for a product built to serve as much of the market as possible, while your needs are narrow.

The economic waste is substantial. Pendo's Feature Adoption Report estimated that $29.5 billion in global cloud R&D investment is squandered annually on software features that go unused. Zylo's 2026 SaaS Management Index reports that organisations waste an average of $17 million per year on unused SaaS licences, with 44% of licences wasted or underutilised. Enterprise organisations with 10,000+ employees spend over $224M on SaaS but only utilise about half of their licences. And 78% of IT leaders report unexpected charges tied to AI features or consumption-based pricing as vendors add new tiers mid-contract.

None of that means SaaS is "bad." It means that when you buy a platform designed for everyone, you get a lot of "everyone" and not always enough "you." Organisations operate with far narrower needs than the platforms they purchase. That gap is where the pendulum finds room to swing back.

GenAI and the Shift Back to Build

What's changed is that building has become cheaper and faster — not in every context, but in enough to matter. GenAI-powered development tooling (Copilot, Cursor, Claude, and the rest) doesn't just speed up typing; it compresses the loop between "we need a thing" and "here's a working thing." A single engineer can now prototype and ship working internal tools, workflows, or dashboards in hours or days that would have taken a small team weeks or months a few years ago.

The numbers back it up. McKinsey's research on AI-driven software organisations shows 16–30% improvements in team productivity and time-to-market, and 31–45% gains in software quality. That's the first potential step-change in developer productivity in decades. And the shift is already happening at scale: Retool's 2026 Build vs. Buy Report found that 35% of enterprises have already replaced at least one SaaS tool with custom software, and 78% expect to build more custom internal tools in 2026. Workflow automation and internal admin tools lead the way; CRMs, BI tools, project management, and customer support are also in the frame.

The advantage of building in this environment isn't just speed — it's fit. An organisation that builds gets exactly what it needs: the workflows it actually runs, the data model it already has, the integrations that matter to it. No feature bloat, no paying for capabilities that will never be used. Bespoke doesn't have to mean "expensive" anymore when the cost of building has dropped.

Build where it differentiates; buy where it commoditises. The line between those two has moved.

The Other Side of the Coin

Choosing to build isn't free. When you stop buying, you take on everything the vendor used to own: uptime, security, compliance (SOC 2, GDPR, whatever your industry demands), patching, and the long tail of maintenance. There's no support team to call when something breaks at 2am. No roadmap promising the feature you need next quarter. Just you and the system you now own.

Retool's same report highlights a sobering pattern: 60% of respondents had built software outside IT oversight in the past year, with 25% doing so frequently. Shadow IT isn't new, but when "anyone can build an app" meets "we're replacing SaaS with custom tools," governance and ownership get messy. BCG's work on accelerating enterprise technology delivery notes that less than half of customised enterprise solution projects run on time or on budget. And there's a well-documented gap between a working GenAI prototype and production-grade software — the figure that 95% of enterprise GenAI pilots fail to reach production is a useful reminder that "we built it in a weekend" and "we're running it in production" are not the same thing.

So the shift back to build isn't a free lunch. Organisations that build are trading vendor lock-in and feature bloat for operational responsibility and ongoing maintenance. They need to be honest about what they're signing up for: who owns this in two years? Who fixes it when the person who built it leaves? Who handles the security review and the compliance audit?

What This Means Going Forward

Where does this leave us? I don't think the answer is "everyone builds everything" or "everyone goes back to buying." The pendulum doesn't settle on one side; it swings, and the smart move is to know where you are in the cycle.

For SaaS platforms, the message is clear: the value proposition of "we do everything for everyone" is under pressure. Tighter, more focused feature sets; better extensibility and APIs; consumption-based pricing that actually reflects value — these will matter more as building becomes a credible alternative. Vendors that assume "they'll never build it themselves" may find that assumption outdated.

For organisations, the question isn't really "build or buy?" It's "what are you willing to own?" Build where the fit matters and the team can sustain it. Buy where the problem is standardised and the vendor's scale and support are worth the premium and the bloat. The line between those two has moved — more problems are now in "we could build this" territory — but the discipline of ownership hasn't changed. Someone has to run it, secure it, and maintain it. If that's you, own the decision.

Closing

The build vs. buy decision has defined enterprise software for decades. First we built because we had to; then we bought because it was faster and cheaper and someone else would run it. Now we're watching the cost of building fall again, and the cost of buying — in wasted features, in lock-in, in surprise AI surcharges — become more visible. The pendulum is swinging back, not to the 1970s, but to a new equilibrium where "build" is a real option for more organisations than it was five years ago.

Knowing where you are in that cycle matters more than picking a side. Build when it serves you; buy when it serves you. Just be clear about what you're taking on either way.