Something significant is happening inside enterprise companies right now—and if you're building SaaS products, you should be paying close attention.
According to a new report from Retool released this week, 35% of enterprises have already replaced functionality from at least one SaaS tool with something they built themselves. Even more striking: 78% expect to build more of their own tools in 2026.
This isn't just another build-vs-buy debate. It's a signal that the relationship between SaaS vendors and their customers is fundamentally broken—and feedback loops are at the heart of the problem.
The Friction Problem Nobody Talks About
David Hsu, Retool's CEO, put it plainly in an interview with Newsweek: "It's almost always narrow workflows first. Nobody's ripping out Salesforce wholesale. What they're doing is replacing the specific piece of a tool that never quite fit."
Read that again: the specific piece of a tool that never quite fit.
These aren't complete product failures. They're death by a thousand paper cuts—approval flows that don't match company processes, dashboards that show the wrong metrics, admin panels that require three extra clicks for a daily task.
The cumulative cost of these small frictions has always existed. What's changed is that the cost of fixing them yourself has collapsed. Hsu estimates that what used to take engineering teams weeks and cost six figures can now be prototyped by a business operations lead in a day or two.
When building becomes that accessible, every piece of misaligned SaaS becomes a candidate for replacement.
The Real Question: Why Don't Your Tools Fit?
Here's where product teams need to get honest with themselves.
If 35% of enterprises are replacing SaaS functionality they're paying for, that's not a technology problem. It's a listening problem. Those misaligned workflows didn't appear out of nowhere—they were built into products by teams who didn't fully understand how customers actually work.
The Retool survey found that 60% of builders created tools outside of IT oversight in the past year. As Hsu describes it, "Shadow IT at this scale is a demand signal."
That's a diplomatic way of saying: your users have been telling you something is broken for years. They just stopped waiting for you to fix it.
The Feedback Gap That Kills Products
Every product team claims to care about customer feedback. Most have some combination of Intercom tickets, NPS surveys, quarterly business reviews, and the occasional user interview.
But here's the uncomfortable truth: the gap between "collecting feedback" and "understanding customer workflows deeply enough to prevent replacement" is enormous.
Consider what happens when a customer reports friction in your product:
-
Support tickets capture the symptom ("Export function is slow") but rarely the full context ("I need to pull this data every Monday for a leadership meeting, and the current 10-minute export means I have to start this process at 6 AM")
-
NPS surveys might catch dissatisfaction, but a score of 7 doesn't tell you which specific workflow is driving someone to build their own alternative
-
Quarterly reviews happen too infrequently to catch emerging patterns, and customers often filter their feedback based on what they think is "reasonable" to ask for
-
User interviews give depth but not breadth—you might deeply understand 20 customers while missing patterns affecting 2,000
The result? Product teams make decisions based on incomplete information, ship features that partially address problems, and then wonder why customers are quietly building alternatives.
What Actually Matters: Continuous Discovery at Scale
The best product teams have figured out that feedback isn't a checkpoint—it's continuous infrastructure.
Teresa Torres has been advocating for years that product teams should be talking to customers weekly, not quarterly. But even weekly interviews don't solve the scale problem. You can't interview every customer every week.
This is where the nature of feedback collection has to evolve. Modern product organizations need to:
Aggregate signals automatically. Every customer touchpoint—support tickets, sales calls, feature requests, cancellation reasons, usage patterns—contains information about what's working and what isn't. The teams winning in 2026 are the ones synthesizing this data continuously, not reviewing it quarterly.
Identify patterns before they become problems. By the time 35% of your enterprise customers are building replacements, the warning signs have been there for months or years. Churn risk indicators, declining feature adoption, increased support volume on specific workflows—these are all signals that something isn't fitting.
Connect feedback to actual workflow context. Understanding that customers want "better reporting" is not the same as understanding that Sarah in Finance needs to generate a specific compliance report every Friday, and the current 17-click process makes her want to throw her laptop through a window.
The Governance Wake-Up Call
Here's another finding from the Retool survey that should give SaaS vendors pause: only 19% of organizations described themselves as having advanced AI automation maturity.
This means 81% of enterprises are somewhere on the spectrum between "experimenting cautiously" and "complete chaos." The same companies building their own tools to replace your product don't necessarily have the governance structures to maintain those tools long-term.
What does this mean for SaaS vendors? There's a window of opportunity.
If you can demonstrate that your product genuinely understands customer workflows—not through marketing claims, but through features that actually fit—you have an advantage over internally-built alternatives that might lack security reviews, access controls, or long-term ownership.
But that advantage only exists if you're actually listening and responding faster than your customers can build.
The Path Forward for Product Teams
If you're leading a product team in 2026, here's what the Retool data should prompt you to ask:
Do we know which parts of our product "never quite fit"? Not in vague terms, but specifically: which workflows have customers complained about? Where do support tickets cluster? What features have declining adoption despite being available?
Are we capturing feedback at the workflow level, or just the feature level? There's a difference between knowing that customers want "improved exports" and understanding the exact business process that export supports.
How quickly do we close the loop? When a customer reports friction, how long until they see a response in the product? If the answer is "next quarter" or "on the roadmap," that might be too slow.
Are we measuring what matters? The Retool survey found that 37% of organizations haven't established AI productivity metrics. The same is likely true for many SaaS vendors tracking vanity metrics instead of actual workflow success rates.
The Bottom Line
The 78% of enterprises planning to build more tools in 2026 aren't doing it because they hate SaaS. They're doing it because the cost of building has dropped while the cost of misfit software—in friction, workarounds, and wasted time—has stayed the same.
For product teams, this is both a warning and an opportunity. The warning: if you're not deeply understanding customer workflows, you're already being replaced in small ways you might not even see in your churn data yet.
The opportunity: the teams that figure out how to continuously discover, synthesize, and act on customer feedback at scale will build products that actually fit. And when building becomes the default question, as Hsu suggests, the products that fit don't get replaced—they become essential.
The question isn't whether your customers are building alternatives. The question is whether you're listening closely enough to make that unnecessary.
Pelin helps product teams transform scattered customer feedback into actionable insights. By automatically aggregating and analyzing signals from Intercom, Slack, Zendesk, and more, Pelin surfaces the patterns that matter—before your customers decide to build their own solutions. See how it works →