Thirty-five percent of enterprises have already replaced at least one SaaS tool with something built in-house, and sixty percent of those builds happened as shadow IT, outside procurement and outside architecture review, according to Retool’s 2026 Build vs. Buy Report. That second number is the one that should keep an EA board up at night, not the first. A tool getting replaced is just the market doing its job. A tool getting replaced by something nobody on the architecture side ever laid eyes on is a governance failure with a delay timer already running on it.
Most companies frame this as “build vs. buy,” and honestly, that framing is broken before anyone even opens their mouth, because it skips the question that ought to come first: does the company already own something that does this? The sequence that actually holds up is reuse, then buy, then build, in that order, with build as the option someone has to earn rather than the one that wins by default because it’s the most fun thing to pitch in a planning meeting.
AI didn’t create the impulse to build, it just removed the tax on it
The “not invented here” instinct isn’t new, I’ve watched it show up on engineering teams for two decades now. Ego, a desire for control, distrust of vendor roadmaps, that combination has always been sitting there. What kept it in check was that building was genuinely slow and expensive, so the instinct rarely survived contact with an actual business case for buying. AI coding assistants took that governor off. A capable engineer, or honestly a technically fluent ops lead with a weekend to burn, can scaffold a working prototype in a sprint or two, call it done, and skip the proposal that never would have cleared the bar a year ago.
What that prototype doesn’t carry with it is the cost that actually matters: patching, access control, uptime, integration maintenance, and the re-platforming scramble that hits the day the person who built it leaves. That cost is invisible at pitch time, because the pitch is usually made by someone optimizing for their own deadline, not for total cost of ownership five years out. I’ll say the quiet part plainly: the hard part of software was never writing the first version. It’s operating it securely for years after the person who cared about it has moved on to something else entirely.
Vendor-led delivery still wins on outcomes, not just on cost
Set the instinct aside for a second and look at what actually ships successfully. MIT’s 2025 State of AI in Business research, the one that’s been widely reported as the “GenAI Divide” study, found that AI initiatives run through external partnerships or vendor-led engagements hit roughly a 67% success rate, compared to about 33% for purely internal builds. That’s a two-to-one gap, and no, it isn’t about model quality. A vendor has solved integration, evaluation, and governance problems dozens of times over. Your internal team, however sharp, is usually solving them for the first time while everything else on their plate is still due.
None of this has slowed the buy side of the market down, and I don’t think it will. Gartner’s latest 2026 forecast puts worldwide IT spending growth at 14.2% for the year, with software spend doing a lot of the heavy lifting. So the same organization is doing two contradictory things at once: buying deliberately at the center, building quietly at the edges. Both numbers are true at the same time, because they’re describing the same governance gap, just measured from two different altitudes.
The sequence only works if something enforces it
None of this means build is always the wrong call, and I’d be lying if I said it was. Regulated data flows, genuine competitive differentiation, integration depth no vendor can match, these are legitimate build cases and always have been. The problem is treating build as a coin flip against buy instead of the last stop on a three-step evaluation:
- Reuse first. Check whether the capability already exists somewhere in the portfolio before a new tool even gets a hearing. This only works if the capability map is current, which is exactly the kind of artifact that rots the moment it lives in a slide deck instead of a system of record.
- Buy second. If nothing exists, evaluate the vendor market against a real requirements list, not a wishlist shaped by whatever prototype someone already half-built over a weekend.
- Build last, and only with a documented reason. Regulatory constraint, genuine differentiation, or integration depth a vendor can’t reach. “We can ship it fast with AI tools” doesn’t belong on that list, because speed to prototype was never the bottleneck that mattered.
The enforcement mechanism is deliberately unglamorous, and that’s the point: every build decision gets an ADR, and every ADR gets logged in an EAM tool, mapped against the current capability and application inventory, before a single line of code ships. I use LeanIX for this myself. The value isn’t the tool, it’s that a build decision made without checking the current-state map is a decision made blind. “What do we already own that does this” should be answerable in minutes by querying the inventory, not by asking around the org chart and hoping somebody remembers.
This is a solution rationalization problem as much as it’s a decision-hygiene one. Every shadow build that skips reuse is one more thing to secure, patch, and eventually retire, stacked on top of tools that already do something close enough. Fiscally, that’s redundant spend wearing a productivity costume. From a risk standpoint, it’s an unreviewed system holding data and access that nobody on the security side ever signed off on. Neither cost shows up in the sprint that shipped it. Both show up eighteen months later as technical debt, or worse, as an incident. I’ve written before about why a federated EA model beats both ivory tower and pure distributed governance, but only when the central function keeps non-negotiable authority over a short list of guardrails. This is one of those guardrails, and it has to be enforced at the board, not left to individual teams’ goodwill (I wish that were enough, but I’ve never seen it be).
Here’s the one change worth making before your next ARB session: add a standing rule that no build request gets a slot on the agenda without an attached reuse-check output pulled straight from the EAM inventory, not a verbal assurance that “we looked and didn’t find anything.” If the board can’t see the query result, the request isn’t ready to be reviewed, full stop. That single procedural gate is what turns reuse-then-buy-then-build from a slogan into something your board can actually enforce.
Photo by Kelly Sikkema on Unsplash