Your team just proved they could rebuild a $20K SaaS tool in two weeks using AI-assisted development. They shipped it, killed the subscription, and your finance team celebrated $240K in annual savings. Then IT found out about it.

This isn't hypothetical. 35% of teams have already replaced at least one SaaS tool with a custom build and 78% expect to build more custom internal tools in 2026. And here's the problem nobody's talking about loudly enough: 60% of respondents have built software outside IT oversight in the past year; 25% report doing so frequently.

The build-vs-buy decision isn't failing because the math is wrong. It's failing because the infrastructure to execute the build decision responsibly doesn't exist yet in most enterprises.

The Acceleration of Build Economics

Let me be direct: the cost dynamics changed fast. The cost fell from $50K–$150K to the cost of a subscription plus time spent describing what you want. A custom CRM that cost $80,000 to build in 2023 can be built in 2 days with low-code AI platforms in 2026. For a 15-person team, Salesforce costs $4,500/year or $13,500 over three years, while a custom low-code build costs ~$612 over three years in platform fees.

That's a 22x swing in TCO. The math isn't theoretical anymore—it's compelling enough to bypass procurement entirely.

Why Teams Are Building in the Shadows

The root cause isn't recklessness. It's friction. When a product team identifies that 80% of their Asana seats sit unused, or when a finance analyst discovers they can automate a manual reconciliation in a low-code platform faster than they can file a requisition for new software, they have a choice: wait six months for IT approval and change management, or ship it and ask for forgiveness.

Under deadline pressure, with AI tools that lower the technical barrier to entry, they build. Many builders are creating software outside IT oversight as development outpaces procurement and governance processes.

The irony: they're making the right financial decision and the wrong operational one simultaneously.

The Technical Debt You Can't See Until It Costs You

Here's what typically happens next, based on patterns I've seen at enterprise scale:

Security exposure. A low-code build inherits the security posture of the platform it runs on—which is often fine. But when that tool connects to your data warehouse, pulls customer records, or integrates with Salesforce, it creates OAuth tokens, API keys, and database credentials that live in the workspace of whoever built it. If they leave, if the team reorganizes, if compliance audits change—those tokens don't retire on their own.

Compliance gaps. IT knows what systems touch regulated data. Finance knows where PII lives. But the custom internal admin tool built by the operations team in Retool? Nobody documented it against your compliance inventory. When NIS2, GDPR, or SOC 2 audits roll around, you discover a tool processing customer data that was never included in your data processing agreements.

Integration debt. Your custom build works fine at 10 users. At 100 users, the third-party API you're hitting throttles. At 200 users, the database you're using hits limits that low-code platforms don't expose until you crash into them. The developer who shipped it is now spending cycles on infrastructure problems they didn't anticipate. You're hiring more engineers to maintain custom software that was supposed to be the alternative to hiring engineers.

Organizational fragmentation. Once the first team ships their custom tool, the precedent is set. Now every department wants to build. You end up with 30 custom applications scattered across three different low-code platforms, using four different authentication systems, backed by none of them consistently. Support costs spike because each one is different.

Why Vendor Consolidation Doesn't Solve This

I've spent the last two years helping enterprises execute vendor consolidation programs. The goal is clear: fewer vendors, clearer spend, simpler stacks. 68 percent of technology leaders are planning to consolidate their vendor landscape, with a majority of organizations targeting a 20 percent reduction in vendor count.

But consolidation assumes you know what's in your estate. When a third of your custom applications live outside IT's visibility, consolidation becomes theater. You're reducing your official vendor count while your actual operational complexity climbs.

Worse: teams building custom replacements are often doing it because they're frustrated with the consolidated platform you just invested three years rolling out.

The Actual Post-Mortem

I've seen three versions of how this fails in practice.

Version one: The cost plays out differently than expected. Your team shipped a custom tool in two weeks. Great. After 18 months, it's handling real production load, and it needs features the original specification didn't include. Now you need either the person who built it to maintain it—tying up capacity—or you need to hire a second engineer who understands the codebase. The "cheaper" build now costs more than the SaaS subscription would have.

Version two: Compliance finds it. An audit turns up the tool. Now you need to retrofit security controls, implement access logging, document it against your data inventory, and prove it meets your standards. That retrofit costs $40K and two months of your security team's time.

Version three: The original builder leaves. The team lead who architected the solution moves to a different department or company. The tool keeps running, but nobody else understands how it works or why certain design decisions were made. Maintenance becomes a black box. When something breaks, the cost to fix it jumps dramatically.

What Actually Needs to Happen

This isn't about killing shadow IT. Shadow IT exists because centralized systems move too slowly. Instead, the fix is threefold:

First, compress the procurement cycle for small builds. If a team can describe what they need in an afternoon, they should have a decision on buying vs. building within a week—not six weeks. Fast procurement beats fast shadow development every time.

Second, establish clear governance before people build. Not after. Have a lightweight template for custom builds that includes: where the code lives, who owns it long-term, what security controls are non-negotiable, and how it integrates with your compliance inventory. Make it an entry requirement, not a violation to punish after the fact.

Third, invest in platform consolidation, not tool consolidation. Rather than choosing between 30 point solutions, give teams a single governance-ready platform—a low-code environment, a cloud native stack, whatever fits your risk profile—and let them build on it with guardrails. This gets you speed without fragmentation.

The Bottom Line

The build-vs-buy math has fundamentally shifted in your favor. But executing that shift without governance creates a new problem that costs more to solve than the original problem you were trying to fix.

I'm not arguing against building custom software. I'm arguing that the faster you make building, the more critical it is that you have visibility and lightweight governance in place before teams start shipping.

The enterprises getting this right are the ones that accepted this truth early: you can't slow down building anymore—so you have to speed up IT's ability to govern it responsibly.