35% of teams have replaced a SaaS tool with custom software. Should you?

In early February, an Anthropic product update knocked billions off enterprise software stocks in a single day. Traders called it the SaaSpocalypse: the market briefly pricing in a world where companies stop buying software and start building it. Two weeks later Retool published its 2026 Build vs. Buy report, and the survey data backed the mood up. Of 817 builders surveyed, 35% had already replaced at least one SaaS tool with something custom-built, and 78% plan to build more this year.

We build custom software for a living, so you might expect us to cheer. Mostly we wince. What the report actually describes is a wave of fast and largely ungoverned building that will produce some real wins and a lot of abandoned tools nobody maintains. Which group you end up in gets decided before anyone writes a prompt.

What the report actually says

First, the caveat the press releases skip: Retool surveyed its own customers and builders, 817 of them, in late 2025. These are people who already bought a tool-building platform. Asking them whether they like building tools is a bit like polling a gym about exercise. The direction is informative; the exact percentages, take with salt.

With that filter on, the findings still say plenty. Every SaaS category is under replacement pressure: workflow automations (35%) and internal admin tools (33%) lead, with BI tools at 29%, CRMs and form builders at 25%, project management at 23%, customer support at 21%. The case studies are concrete. ClickUp built six internal AI tools and cut $200K a year in automation software. Harmonic got fed up with a $20,000-a-year tool whose support was slower than rebuilding the product, so they rebuilt it, and now run 33 internal apps.

And then the stat that should slow you down: 60% of builders shipped something outside IT oversight in the past year. Asked why, they said they could build faster than IT could procure (31%), the existing SaaS didn't do what they needed (25%), or IT's process was simply too slow (18%). These aren't interns with a weekend project; 64% of respondents were senior managers or above.

Why the math flipped

For twenty years the build-vs-buy calculation was stable. Building meant hiring engineers, waiting two quarters, and owning maintenance forever. Buying meant a credit card. For anything that wasn't your core product, buying won by default, and it was usually the right call.

AI didn't adjust that calculation. It knocked one side of it over. A working internal tool (a dashboard, an approval workflow, a CRM-shaped thing that matches your slightly weird sales process) is now days of work, sometimes hours. When the build costs that little, a $15,000 subscription for software your team half-uses stops being a safe default and starts being a line item somebody should question.

But notice what the subscription had going for it: a price tag. You knew what it cost. A custom build hides its costs in places finance doesn't look, and that's exactly where this is going wrong at a lot of companies right now.

The part nobody budgets for

The same report lists the top organizational blockers for automation: unclear ROI (33%), budget (30%), maintenance burden (26%). And 35% of organizations have established no AI productivity metrics at all. Put those together and you get the uncomfortable picture: companies are swapping measurable subscriptions for unmeasured internal tools, at scale, often without IT knowing the tool exists.

We've written before about the Month 3 Problem in AI-assisted development: the prototype arrives fast and feels like magic, and the bill shows up around month three, when the thing suddenly needs auth, permissions, audit logs, and someone on call. Internal tools follow the same arc. The ops lead who built the dashboard changes teams. The API it leans on changes shape. Nobody else can read the generated code. Now a chunk of your revenue operations runs on a tool with a bus factor of one.

There's no way you can go live with a vibe-coded solution. It might work for demos, but we build enterprise-grade technology that has to scale across 30 countries.

That quote is from Pierre Yves Calloc'h at Pernod Ricard, in the same Retool report that celebrates the building wave. Both things are true at once. The building is real and the wins are real, and the production bar hasn't moved an inch.

There's a precedent for how this goes if you skip the measurement. Gartner predicts that half of the companies that cut customer service staff for AI will be rehiring those roles by 2027. Software can follow the same loop: cancel the subscription, enjoy the demo, quietly re-subscribe in eighteen months after the internal tool rots. Retool's own report puts it well: replacement without measurement is just churn.

A short decision framework

Replace when the tool is generic and your process isn't. The categories topping the pressure list (workflow automation, internal admin, dashboards) are mostly thin software layers over your own data. If you're paying for a hundred seats and using twelve, or paying for two hundred features and using nine, fit beats features and custom wins. The Harmonic story is the template: the moment the subscription costs more in workarounds than the build would cost in total, build.

Keep buying when your process isn't special (payroll, accounting, email), when compliance is the actual product, or when the value is the vendor's ecosystem rather than its screens. Nobody should hand-roll the system that keeps them HIPAA compliant to save $400 a month.

And whatever you build, make it boring on purpose: a real repository, access control, error monitoring, an owner whose name everyone knows, and one number you check: hours saved, tickets closed, or dollars cut. That's the whole difference between an asset and a liability. The Retool data shows builders already understand this instinctively: 72% of the people shipping real software use AI to write pieces of code they test and integrate, while only 31% prompt their way to complete apps. Production software lives in the first group.

That gap between a prompted prototype and a tool your company can depend on is where teams like ours get called in, usually around month three. The prototype isn't wasted work, to be clear. A vibe-coded tool that your ops lead built and the whole team already uses is the best requirements document we've ever been handed. It just isn't the finished product, and treating it like one is how the re-subscribe loop starts.

So, should you? If a tool on the high-pressure list is expensive, half-used, and wrapped around your own data: probably yes, and the economics will only tilt further that way. Just answer one question before you cancel anything: who owns this in month three? If there's a name, build. If there's a shrug, keep paying.