Essay
SaaS Fatigue: Why Your Users Don't Want Another Tool (and What to Ship Instead)
Short answer: SaaS fatigue isn't users getting tired of software. It's users refusing to pay the per-tool cost: one more signup, one more login, one more subscription, one more tab, one more inbox of onboarding emails. Building software got close to free, so the number of products asking for that cost exploded, and users' patience didn't grow with it. For a small SaaS, the answer isn't a better landing page. It's to stop asking users to come to you and show up inside the tools they already have open, with the tool's owner earning a share of what you sell there.
From the video:
Speaking as a user rather than a founder: I don't want fifty tools selling me their apps on TikTok. I don't want ten emails a day about trying some tool. I don't want DMs everywhere I look. And when I have one problem, I don't want to find ten different micro SaaS products and pay ten subscriptions to solve it.
Every founder reading this has said the same about other people's products. Then we go back to our desks and build an eleventh.
What is SaaS fatigue?
SaaS fatigue is what happens when the cost of adopting another tool outweighs the value of using it. That cost has very little to do with the price. It's everything around it:
- Creating another account and choosing another password.
- Learning another interface.
- Moving data in, and later moving it out.
- Remembering the tool exists and which tab it lives in.
- Another subscription to track, another renewal to cancel.
- Another stream of emails and notifications.
Each of those is small. Together they make a fixed tax on every new product, paid by the user before they've received any value. When users have paid that tax twenty times this year, they stop paying it, however good the twenty-first product is.
There's a second layer to it. Users don't go out to solve micro problems. They have one bigger problem, and solving it means solving a string of small ones along the way. When ten micro SaaS products each solve one of those small problems, the user has to find all ten, decide whether to trust each one, and pay ten subscriptions to get one thing done. Meanwhile all ten are competing for the same user's attention in the same feeds. What the user actually wants is one place where everything they need for the bigger problem is already waiting.
Why is SaaS fatigue getting worse?
Because building got cheap and attention didn't.
With coding agents, a capable founder can build a working product in days. So a lot of people did, and new products now arrive every day, each asking for the same thing: come to my site, sign up, try me. The supply of software went up enormously. The number of new tools a person is willing to adopt in a month stayed roughly where it was.
That's the same shift we described in software becoming a commodity, seen from the other side of the screen. When anyone can build, building is no longer the hard part. Getting adopted is.
What does SaaS fatigue mean for a small SaaS?
Your real competition isn't the other product in your category. It's the user's unwillingness to open another tab.
That shows up in your numbers in familiar places: visitors who never sign up, sign-ups who never come back after day one, trials that end without anyone having really tried. It's tempting to treat each of those as a funnel problem and fix it with a better onboarding email. But the email is part of the tax.
One line we keep coming back to: every tab is a tool that failed to come to the user.
Why don't normal integrations fix it?
Most SaaS integrations are data syncs: "connect your CRM", so that when something happens in one database, something happens in the other. They're useful, but they don't touch the problem, for two reasons.
- The user still has to open both tools. A sync moves data between tabs. It doesn't remove one.
- They mostly flow towards the biggest platform. A small product integrates with a large CRM so the CRM's users will accept it. The small product gives its data away and gets very little back. The user ends up with the big tool plus one more.
If your integration's only job is to move data into somebody else's product, it makes you easier to tolerate. It doesn't make you easier to adopt. (The difference between a widget and an API integration is exactly this.)
What actually fixes it?
Delivering the feature where the user already is.
Instead of asking users to come to your site, you package one feature of your product so it can run inside another product they already use: an interface they can see and use, not just a data pipe. The host's users get your feature at the moment they need it, without a new tab, and often without a new account. The host earns a share of every sale that comes through it, which is why it's worth their while to give you the space.
Take it one step further and you get the goal worth aiming for. Give the user every solution they need, in the order they need it, with as little switching between tools as possible. Ideally they meet each one just before they realised they needed it. That's what we mean by a scenario: several products serving one customer at different steps of the same job, showing up inside each other instead of competing for tabs.
| Ask users to come to you | Show up where they already are | |
|---|---|---|
| First contact | An ad, an email or a post | Inside a tool they already opened |
| Before any value | Sign up, log in, learn a new interface | Use the feature right there |
| Trust | You have to earn it from zero | Borrowed from a host they already trust |
| Subscriptions | One more to manage | Often billed inside the host |
| Who pays to get you noticed | You, in time or money | Nobody upfront; the host earns a share of sales |
What makes it hard?
It'd be dishonest to stop there. Building between tools brings its own costs.
- Coordination. Two teams, two roadmaps, two release schedules. Someone has to keep track of what the other side is changing.
- Code never stands still. Every API change on either side can break the integration, and someone has to own fixing it. (Why integrations break after launch, and how to plan for it.)
- Money. If the host doesn't earn from the integration, it has no reason to keep it working. Agree the split before anyone builds anything.
And it isn't right for every product. If yours is the tool people live in all day, like the editor, the inbox or the CRM itself, then you're the host, and the move is to invite others in rather than move out.
How do you tell if your product should ship as a widget?
Four questions:
- Is there a moment, inside another tool, when your user needs you? Not "our users also use X", but "right after they do Y in X, they need us".
- Can one feature stand on its own? Not the whole product. The one thing that solves the problem at that moment.
- Can someone get value from it in under a minute, without a new account?
- Would the host's users pay for it? If yes, the host has a reason to put it in front of them.
If you answer yes to all four, read what a widget integration is and how to sell a SaaS feature as a widget.
Where Ordana fits
Ordana is a free directory where a SaaS can list one of its features as a widget that other startups can add to their products. The widget's owner sets the host's share of each sale, and Ordana can run the billing inside the widget and split every sale automatically. You build the widget yourself; Ordana takes care of the listing, the terms and the money.
Frequently asked questions
What is SaaS fatigue?
SaaS fatigue is users' growing reluctance to adopt new software tools. It isn't usually driven by price. It's driven by the per-tool cost of another signup, login, interface, subscription and stream of notifications, paid before the tool has delivered any value.
Why are users tired of new apps?
Because building software has become so cheap that new products arrive every day, each asking users to visit, sign up and learn something new. The number of tools a person is willing to adopt hasn't grown to match, so each new product faces a more tired, more sceptical user.
How can a small SaaS deal with tool fatigue?
Stop asking users to come to you. Package one feature so it can run inside a product your users already use, at the moment they need it, and give the host a share of the sales it brings. Users get the value without another tab or account, and you borrow the host's trust.
Do integrations solve SaaS fatigue?
Data-sync integrations don't, because the user still has to open both tools. Integrations that put a usable feature inside another product, often called widgets, do, because they remove a tool from the user's day rather than connecting two of them.
Should every SaaS become a widget?
No. If your product is the one people live in all day, you're the natural host, and the better move is to invite other products in. A widget suits products whose value happens at a specific moment inside someone else's workflow.
Related reading:
- Software Is a Commodity Now: What That Means for SaaS Distribution: the supply side of the same shift.
- What Is a Widget Integration?: how one product shows up inside another.
- Widget vs API Integration: Which Should Your SaaS Offer?: why a data sync isn't enough.
- Why Doesn't the West Have Super Apps?: what users get when small apps click together.