The product was rarely why people canceled. Four things that actually showed up across 13 SaaS teardowns.
I scored public cancellation feedback for a dozen well-known SaaS companies.
G2, Hacker News, the threads people write when they walk. Slack, Figma, Notion, Linear, Evernote, Calendly, HubSpot, a dozen more.
What surprised me: the product was almost never the reason.
Figma's editor is still best in class. Linear is still one of the best built tools out there. People didn't leave because the software got worse.
They left over four things, and it was the same four every time.
1. The bill changed after they were committed.
Not a number on a pricing page. A number that moved once leaving got painful.
One Slack customer on HN: "Onboarded one price, rebilled at three times that." A Calendly user said the price went up a year in and they switched in an afternoon. Monday.com runs a cancellation-warning banner every team member sees daily, on top of random increases.
The cancel decision gets made the moment the number moves, not when a feature ships.
2. Per-seat pricing punished the teams that grew.
The customers who succeed with you are the ones the meter turns on.
A Linear review nailed it: "amazing for 10 engineers, brutal for 80 because it's per seat." A HubSpot user watched a seat restructure 5x their bill overnight.
You build the price to scale with the customer, then act surprised when scaling is the exact thing that makes them leave.
3. They paywalled something the customer already had.
Different from raising a price. This is pulling an existing thing behind a higher tier.
Asana moved SSO to the top tier and a customer said compliance forced their hand. Evernote slashed the free tier to 50 notes after years. A HubSpot user described paying "to restore features we already had."
Taking something away reads as a different kind of betrayal than charging for something new.
4. The switching cost they were counting on was a bluff.
Every one of these companies assumed lock-in protected them. Mostly it didn't.
Calendly: "switched to a competitor in an afternoon, did not lose a single booking." Figma lost 40 designers to Penpot in two weeks after a 33% hike.
The moat you think you have is theoretical until someone's annoyed enough to test it. Then you find out.
Through line for me: churn here is a trust event, not a quality event.
People don't cancel the day the product disappoints them. They cancel the day the money or the access changes in a way that feels like the deal moved. The feedback reads like a diary of that moment, not a product review.
Curious from the operators here: when you've lost customers, was it actually the product, or was it one of these four?
I'd separate 'charging more' from 'changing the deal' here — your four all look like pricing problems, but none of them is about the number on the pricing page. New-customer price hikes basically never show up in cancellation threads; retroactive ones fill them. That distinction is oddly hopeful for indies: you can reprice the product whenever you want, as long as the people who already trusted you keep the terms they signed up under. I build a small memo app solo, and a noticeable share of my earliest users were refugees from Evernote's free-tier cut — your point 3 was literally an acquisition channel for me. Did the teardowns show whether annual vs monthly billing changed how fast people walked after the bill moved?
Your annual-vs-monthly question is the one I can't stop chewing on, because you'd actually know. You inherited a whole cohort that got burned by exactly the point-3 takeaway.
If you've got cancel notes from that crowd, I'll run the same teardown on them and send the writeup, free. My hunch is your churn looks nothing like the 13, because your users showed up already once-bitten, but I'd rather read it than guess. Happy to figure out a handoff if you're up for it.
Genuinely flattered, but I'd be handing you an empty folder — the app's a one-time unlock, no subscription, so there's no cancellation event to capture notes from. My churn is silent: people just stop opening it, and I only catch it in the install-to-day-7 drop. What I can tell you about the once-bitten crowd, though, is that they don't churn loudly. An Evernote refugee won't send an angry cancel note; they vanish at the first whiff of "here we go again" — one bloated release, one nag screen — because being burned once turns them into flight risks who don't file a complaint first. So the signal I'd actually want out of your 13 isn't the cancel notes, it's the people who never wrote anything and just drifted off. Did any teardown manage to reach the silent ones?
The teardowns can't cleanly split annual vs monthly, they're built from public cancel threads, not billing records. So take this as pattern, not data: annual users tend to show up loud at the renewal, one surprise bill, a lot of betrayal language. Monthly users churn quieter and earlier, they just stop, less public anger because the stakes per charge are smaller.
The Evernote-refugee thing you hit is the cleanest version of point 3. A paywall on something people already had doesn't read as a price change, it reads as a takeaway, and the takeaway is what they don't forgive. You inherited a whole cohort that got burned by exactly that.
When your earliest users walked, was it a slow fade or a hard stop at a specific moment?
The thing I can't stop thinking about: every data point here is someone who already canceled, so by design you're only seeing the moves that failed. Somewhere out there are companies that raised the price or moved a feature behind a paywall and kept their customers anyway. Did any of that show up in your sources, or is the retained side basically invisible from cancellation threads? Trying to work out if these four are death sentences or just unforced errors.
You're right that the sources are survivor-blind by construction. Every voice in a cancel thread is a move that failed, so the retained side is mostly invisible from this vantage.
The one place it leaks through: the companies that raised price or paywalled a feature and kept people show up as the exception someone cites. "X did this and I stayed because they told me first." Same mechanical change, opposite outcome, and the difference is never the number, it's whether trust got managed before the bill landed.
So I read the four as unforced errors, not death sentences. The price move isn't fatal, the silence around it is. The ones you've watched survive a change, did they tend to over-communicate it first?
Mostly yes, but the framing that's held up for me is less "over-communicate" and more "who said it, and when." The survivors I've watched didn't just send the notice early. They made the change feel like it came from a person who'd actually been around, and they timed it to land after people had already gotten something out of the tool, not before. The same email from a faceless "the team," sent a month sooner, still reads as cover instead of candor.
The trap with over-communication is that it only works if you were communicating before there was bad news. A sudden burst of warmth right ahead of a price move reads as exactly what it is. If the account went quiet for a year, the heads-up doesn't build trust, it spends trust you never banked.
One thing from the small-tool side, since that's where I sit: when the builder and the user are about one degree apart, a price move is survivable in a way it isn't for a big platform, because the user can reply to a real human and actually get an answer. Most of the companies in your teardowns couldn't offer that even if they wanted to. Did any of your survivors keep that personal touch as they scaled, or did it only hold while they were small?
Mostly it broke as they scaled, and that's the tell. The personal touch was never about founders being nice. It's structural: when the person who changed the deal is reachable, a price move is aconversation.
Once they're behind a support queue, the same move is just an announcement you react to. The few who kept it didn't stay small, they guarded one channel on purpose, so an existing user could always reach a human who could still say yes.
Did the ones you saw stay personal by staying small, or by protecting that
channel deliberately?
That distinction lands it for me. Not small, just deliberate about keeping one human reachable. The teams that survived a deal change kept a door an existing user could still walk through, and they refused to automate it shut even as everything else scaled. The ones who got torched had closed that door long before the price ever moved, so the change arrived with nobody to appeal to. Protect the channel, not the size. That's the part I'm keeping. Good thread, thanks for actually scoring all these instead of guessing.
The “product was rarely why” point is painfully true for mobile utilities. With Kinetic Override I am treating the Android permission wording, local-profile explanation, and first-run gesture test as part of the product, because users decide whether a macro recorder feels safe before they ever build a useful loop.
The permission-prompt vs loop-didn't-fire split you raised is the exact thing. A macro recorder lives or dies on feeling safe before it's useful, and that verdict lands way earlier than most builders measure.
If you ever want a second set of eyes on Kinetic Override's own drop-off, I'll run the same teardown on whatever cancel or churn notes you've got, free, written report back. Curious whether your bleed is the permission gate or the second session. Say the word and I'll sort out a way to get your data over.
Treating permission wording and first-run as part of the product is exactly right, that's trust before value. A macro recorder lives or dies on whether it feels safe before it's useful, and that verdict happens way earlier than most builders measure. Are you seeing drop-off at the permission prompt itself, or later once they've built a loop and it doesn't fire how they expected?
The "churn is a trust event, not a quality event" framing is sharp. I review SaaS and AI tools for a living, so I watch this from the outside — and your four points line up almost exactly with the reviews that go from glowing to scathing overnight. The pattern I'd add: the betrayal isn't just the price or the paywall, it's the silence around it. The tools that survive a price change are the ones that explained it before the bill landed. The ones that get torched changed the deal quietly and let users discover it on the invoice. Same increase, completely different churn outcome, purely down to whether trust was managed. Your point 3 (paywalling what people already had) is the one I see generate the most permanent damage — that's the one nobody forgives.
"The betrayal is the silence around it" is the sharper version of what I was getting at, I'm stealing that. Glowing-to-scathing overnight is the outside view of the same trust event, the product didn't get worse, the deal did. From the review seat, do the survivors actually explain the change in-product, or is it usually after the fact in a changelog nobody reads?
Honestly, almost always after the fact. The ones that survive tell you before you log in and find out — an email a week early, a heads-up, existing users kept on the old price for a bit. A changelog is where you go to confirm you got screwed, not where you find out. "Technically we disclosed it" is not the same as "we told you."
That line's going on a sticky note. "Technically we disclosed it" is the legal version of telling someone, and people feel the difference instantly.
The part I'd add from the build side: the timing of the heads-up is doing more work than the words. A week-early note from a name you recognize reads as respect. The same email auto-fired the morning the charge hits reads as cover. Same disclosure, opposite signal, and the only variable is whether it landed before the user had a reason to be angry.
Counter from the review seat though: ever watched a tool change the deal quietly, do everything wrong, and survive anyway because switching was just too painful? Trying to work out if trust is the whole story, or if lock-in can paper over a betrayal.