78% of Teams Are Building Their Own Tools — Here's What They're Getting Wrong

Retool just dropped its 2026 Build vs. Buy report, and the numbers tell a story that would have sounded insane three years ago. 78% of teams expect to build more custom internal tools this year. 35% have already binned at least one SaaS tool in favour of something they built themselves. Over half have shipped production software using AI. And nearly half are saving six or more hours a week by building with AI.

This isn't a trend. It's a structural shift.

The report, based on a survey of 817 builders across engineering, operations, IT, and data teams, confirms what a lot of us have been feeling: the old build-vs-buy calculus has stopped making sense. When an operations lead can spin up a working prototype in a couple of days instead of waiting six months for an engineering team and a procurement cycle, the spreadsheet tilts hard toward build.

And AI is the accelerant. The report found 51% of teams have already shipped production software using AI coding tools. That's not tinkering. That's real software, in production, built by people who three years ago would have been filling out a vendor RFP. By people who might not even sit in an engineering org.

The number everyone should be talking about

But here's the stat buried in the report that's more interesting than the headline: 78% of teams expect to build more in 2026. That's ambition. That's momentum. That's also a governance time bomb.

Let me explain.

When 78% of teams are building custom tools, you're not looking at a few skunkworks projects in marketing. You're looking at a parallel IT estate. Hundreds of tools, built by different people, on different platforms, with different standards. The question stops being "should we build or buy?" and becomes "who owns all this stuff?"

Retool's own framing of the report leans into this. The subtitle mentions 'Shadow IT' alongside vibe coding. And they're right to name it. 35% of enterprises have already replaced at least one SaaS product with something custom. That custom tool now has users, dependencies, and an implicit SLA. Someone needs to maintain it. Someone needs to onboard new hires onto it. Someone needs to make sure it's not leaking data.

In most of those 35% of cases, I'd bet nobody has been assigned.

The maintenance iceberg

Here's the uncomfortable truth about building your own tools: the build is the cheap bit now.

AI-assisted development has collapsed the upfront cost. A tool that would have taken two engineers a month now takes a single ops person a few days. Retool's data on time savings backs this up. But what happens on day 90, when the person who built it has moved to a different team? What happens when the API it depends on changes? What happens when there's a security vulnerability in a dependency and nobody's watching?

SaaS vendors charge what they charge partly because they're bundling maintenance, security patching, uptime guarantees, and support. When you rip out the SaaS and replace it with something custom, you're not saving the full subscription cost. You're trading a predictable expense for an unpredictable one. Sometimes that trade is absolutely worth it. But pretending the cost disappears is how you end up with a graveyard of half-maintained internal tools that everyone uses and nobody owns.

I've seen this in companies of every size. The tool someone built in a weekend becomes mission-critical by accident. Six months later, when it breaks, the original builder has left and nobody knows how it works. I've also seen the opposite: someone builds a tool, the team loves it, and the builder gets so buried maintaining it that they can't do their actual job anymore. Neither outcome is great.

What actually needs governing

The governance problem isn't about stopping people from building. That ship has sailed, and honestly, it should have. The 78% isn't a problem to solve. It's evidence that teams know their own problems better than central IT ever could.

The governance challenge is about three things that nobody's talking about enough:

Ownership. Every custom tool needs a named owner, a fallback owner, and a documented path for what happens when both leave. Not a committee. A person.

Security posture. AI-generated code creates an interesting tension. You can build faster, but you're also generating code at a speed that makes traditional code review impractical. The Retool report hints at this with the 'outside traditional enterprise guardrails' language. If your team can ship to production in days, your security review process needs to operate at the same speed. Most don't.

The onboarding tax. SaaS tools come with documentation, support teams, and an internet full of tutorials. Your custom tool comes with whatever the builder remembered to write down. Multiply that by the 78% of teams now building, and you've got a knowledge transfer problem at scale.

Build isn't winning. Build-and-forget is losing.

The most honest reading of Retool's data isn't that build has won over buy. It's that the decision is more nuanced than it's ever been. Some things are better built. Things that encode proprietary process. Things where off-the-shelf tools force you into workflows that don't match how you operate. The 35% who've already replaced SaaS probably got those decisions right.

But some things should still be bought. Anything that's a solved problem. Anything where compliance requirements are complex. Anything where the maintenance burden would swamp the build savings.

The 78% number is exciting. I get why Retool leads with it. But the number I'd watch more closely is whatever that 78% looks like in 2028, after two years of maintenance debt has accumulated.

Build isn't the hard part anymore. Owning what you build is. And right now, most teams are only doing the first half.