Somewhere in your company right now, a small team has probably already built the thing they were supposed to request through procurement. Not out of rebellion. Because building it themselves, with AI doing a lot of the typing, took less time than filling out the form.
That's not a story about AI killing enterprise software. It's a story about a boundary quietly moving. For twenty years, the safe answer to the build vs buy enterprise software question was almost always buy it. That made sense under the old cost structure. It's starting to stop making sense, and the honest reason why is narrower and more interesting than “AI changes everything.”
Why “Buy Configurable” Beat Custom Software Development for Twenty Years
McKinsey's own research puts a number on something most IT leaders already feel: 70 percent of Fortune 500 software was built more than two decades ago. That's not a story about neglect, it's about paralysis. Renovating those systems, the kind of legacy modernization work every large IT department eventually has to face, has historically meant a cost, timeline, and risk profile nearly impossible to defend to a board, so companies kept buying instead.
Buying felt safe partly because the risk was shared with a vendor everyone else was also using. Nobody got fired for buying SAP. But that safety was never as complete as it felt, and off-the-shelf software was never quite the risk-free choice it was sold as internally. Panorama Consulting Group has published an annual ERP implementation report for years. In most editions, it finds that roughly half of ERP projects run over budget. Large-enterprise implementations routinely cost millions of dollars, and timelines regularly stretch past the original plan. Their most recent report shows fewer organizations reporting overruns than in prior years, a real improvement worth taking seriously. But even in a better year, enough projects run long and over budget to sustain an entire consulting industry built around managing that risk.
The point isn't that ERP projects are doomed. It's that “buy configurable” was never actually the low-risk choice it was sold as internally. It just moved the risk into a budget line that stopped getting scrutinized once the contract was signed.
The Old Case Against Custom Enterprise Software Wasn't Wrong
To be fair to every CIO who defaulted to configuration over code, the tradeoffs were real: longer timelines, dependency on the engineers who wrote the system, no vendor SLA, a higher perceived upfront cost. None of that was imagined, and it's exactly why configure-don't-code became the safe default even when everyone quietly knew platform economics were far from perfect. What's changed isn't that the tradeoff was always a myth. It's that the underlying cost curve for building custom has shifted enough to deserve a second look.
What AI-Assisted Software Development Actually Changes, and What It Doesn't
Adoption of AI coding assistants is no longer a leading-edge behavior. Stack Overflow's 2025 Developer Survey, run across nearly 50,000 developers, found 84 percent now use or plan to use AI tools, up from 76 percent the year before. But the same survey found trust in the accuracy of those tools actually fell, from 40 percent in 2024 to 29 percent in 2025, even as usage climbed. Developers are adopting these tools faster than they're learning to trust them.
McKinsey's own lab research with its developers found real gains, in some cases cutting time spent on tasks like documentation and new feature code by roughly half. But the same research is explicit that those gains shrink below 10 percent on tasks rated high in complexity, particularly unfamiliar frameworks, and that less experienced developers sometimes took longer with the tools than without them. METR, an independent research nonprofit, ran the most rigorous test of this question so far: a randomized controlled trial with experienced open-source developers working in codebases they knew well. The result surprised the researchers themselves. Developers using AI tools took 19 percent longer, despite believing both before and after that the tools had made them faster. METR frames that as a snapshot from early 2025, not a permanent verdict, and its own early-2026 follow-up shows the estimate moving toward a modest speedup instead, with wide uncertainty attached.
Put together, that's a consistent finding, not a contradiction. AI reduces the cost of scaffolding, boilerplate, and well-understood tasks, the mechanics of AI-native development that make quick, disciplined builds possible. It does not reduce the cost of architecture, integration, security review, governance, or the maintenance burden that shows up long after launch, especially on complex or unfamiliar work. That's also why the more disciplined cousin of vibe coding, spec-driven development, where requirements and architecture get written down before an AI touches the keyboard, tends to hold up better once a system has to survive contact with production. Those costs are still human judgment calls, and in most enterprise software, they're the majority of what makes a system expensive to own. That's the part a lot of AI coverage skips past.
The Real Shift in Enterprise Architecture: Unbundling, Not Replacement
This is the load-bearing argument, and it's easy to overstate if you're not careful. Every large enterprise's architecture has roughly three layers. There's the core: finance, compliance, audit-heavy systems of record, the stuff that has to be right, auditable, and defensible to a regulator. There's the edge: customer-facing products and genuinely differentiated capabilities, already candidates for custom software development long before generative AI existed. And there's the middle: internal tools, department workflows, approval chains, and one-off processes companies have historically bent themselves around, because building something custom for a single department used to be too expensive to justify against buying another platform module.
The middle is where AI's real strengths, familiar patterns, well-scoped tasks, boilerplate-heavy work, line up almost exactly with what these tools are actually good at. A department workflow tool doesn't need the integration depth or maintenance guarantee a core ERP module needs, so the costs AI is good at reducing make up a much larger share of its total cost. That's the mechanism, not “AI writes code faster” in the abstract. The fixed costs of building something bespoke, the part that used to make custom uncompetitive against configuration, have come down specifically for the kind of work the middle layer is made of.
The core isn't going anywhere, and this isn't a “SAP is dying” argument. If anything, SAP's own positioning proves the point. At Sapphire 2026, CEO Christian Klein framed the company's strategy around embedding AI into the existing platform rather than treating it as a threat, describing the goal as an “Autonomous Enterprise” built on SAP's Business AI Platform, and was direct about the bar core systems have to clear: “Eighty percent accuracy isn't sufficient when running mission-critical businesses. AI must work at enterprise grade, accurate, compliant, and secure.” That's the core layer's logic in one sentence, and exactly why the core and the middle are on different trajectories.
A Simple Governance Framework for the Build vs. Buy Decision
Before renewing a platform contract or greenlighting a custom build, four questions sort the build vs buy enterprise software decision quickly:
1. Core or middle layer?
Compliance-critical or differentiated functions stay core, regardless of what AI can do. Workflows a team bent itself around to fit a vendor's design are middle-layer candidates.
2. Is the scope well-bounded?
AI-assisted development has real evidence behind it on familiar, limited-scope work, and against it on complex, deeply integrated work.
3. What's the honest five-year cost?
Compare the platform's full cost, not the license alone, against a custom build at current AI-assisted speed.
4. Who owns it after launch?
AI can help write the code. It can't own the enterprise architecture, security, or maintenance once the person who built it has moved on, and that ownership question is where enterprise IT governance either shows up or doesn't.
Where Expeed Fits Into Enterprise AI Development
We build software for a living, and we've watched teams assume AI-assisted software development means everything is suddenly a candidate for a quick custom build. Some were right. A number weren't, because the project looked like a middle-layer workflow tool on the surface but actually needed the integration depth or governance of something closer to the core.
At Expeed, the question we push clients toward isn't build or buy. It's which layer a system belongs in, and whether the team taking it on is set up to own everything AI doesn't. That's the lens we bring to enterprise AI development and to custom enterprise software solutions more broadly. The middle layer is real, and it's growing. Treating everything like it belongs there is how good ideas turn into production incidents.
FAQ
1. What is the build vs buy decision?
The build vs buy decision is the choice enterprises face whenever they need new software capability: buy an off-the-shelf platform or configurable SaaS product, or invest in custom software development to build something purpose-built in-house. For most of the last two decades, buying configurable platforms was the default because it transferred risk to a vendor. As this piece has argued, that safety was always more limited than it looked, and the calculus has shifted further with AI-assisted development.
2. Has AI changed the build vs. buy decision for enterprise software?
Yes, but narrowly, not universally. AI-assisted software development has lowered the cost of the boilerplate and scaffolding work that used to make custom builds uncompetitive against buying, particularly for well-scoped, department-level tools. It hasn't changed the economics for core, compliance-critical systems, where architecture, integration, and governance costs still dominate and AI coding assistants offer only marginal gains.
3. Is it cheaper to build custom software than buy SaaS in 2026?
It depends on what's being built. For narrow, well-bounded internal tools, AI-native development can make a custom build genuinely cheaper and faster than negotiating, configuring, and maintaining another SaaS subscription. For core systems tied to sensitive data or regulatory requirements, off-the-shelf software with vendor support still tends to be the safer, and often cheaper, option over a five-year horizon once architecture, security review, and maintenance are counted.
4. When should an enterprise build instead of buy?
Build when the workflow is genuinely differentiated, well scoped, and living in the middle layer of enterprise architecture, department tools, internal processes, and integrations, rather than the compliance-critical core. It also makes sense when a team has the enterprise IT governance in place to own the system's architecture and maintenance after launch, not just the code that gets it out the door.
5. What are the risks of building custom software with AI assistance?
The main risks aren't in the code AI writes, they're in what AI doesn't do: architecture decisions, integration with existing systems, security review, and long-term maintenance. Research from McKinsey and METR both show AI's productivity gains shrink or disappear on complex, unfamiliar work, which is exactly the profile of a poorly scoped custom enterprise software project. Enterprises that treat every internal request as a vibe coding candidate, without spec-driven development discipline or clear ownership, are the ones most likely to end up with unmaintainable systems.
6. What is “vibe coding” and why does it matter for enterprise software strategy?
Vibe coding is a term for building software largely by describing what you want and letting an AI coding assistant generate the implementation, with less upfront specification than traditional development. It matters for enterprise software strategy because it's made department-level custom software development fast enough to compete with buying and configuring another platform module, at least for well-scoped internal tools. It's a poor fit for core, compliance-heavy systems, where spec-driven development, with clear requirements, architecture, and review, remains the more defensible approach.
