2
5 Comments

I ignored churn for years and it quietly capped every SaaS I built

I've launched a handful of SaaS products. Most flopped. The ones that got traction all taught me the same painful lesson, and I wish I'd learned it earlier: I was obsessed with getting new customers and completely blind to the ones quietly leaving out the back door. I'd celebrate signups while roughly the same number churned, running up a down escalator without realizing it.

When I finally dug into the churn data, two things genuinely surprised me:

  1. By the time a cancellation shows up in your revenue number, the customer decided to leave weeks earlier. Churn is a lagging indicator — the warning signs (usage dropping, a key user going quiet, a failed payment) are all there before the cancel, if you're looking at leading indicators instead of last month's MRR.

  2. A big chunk of "churn" isn't people choosing to leave at all — often 20–40% is cards that silently failed and dunning never recovered. The customer never decided anything; the payment just quietly died. And it's usually the easiest revenue to win back, because they weren't even unhappy.

That second one broke my brain a little. Most dashboards lump both together as one "churn" number, so you end up fixing the wrong problem.

I got obsessed enough with this that I ended up building a tool around it (Exeechain), but honestly the lesson stands with or without any software: retention is a leading-indicator game, and most of us only watch the lagging number.

Curious how other founders here handle it: do you separate voluntary churn from failed-payment churn? And have you found any signal that reliably tells you a customer's about to leave before they do?

Happy to share more of what I found in the data if it's useful — and if anyone wants their own churn broken down (voluntary vs failed-payment split), I'm genuinely happy to do a few for free.

posted toAvatar for product Exeechain
Exeechain
  1. 1

    Haven't built anything to separate the two yet, but this hits close to home — I've been digging into the same lagging-indicator problem. Curious what you found in the data that actually holds up as an early signal vs just noise. Did any single behavior pattern show up consistently before the drop-off?

    1. 1

      Honestly? Nothing held up on its own. Which is kind of the answer.

      Usage dropping is noisy as hell. People go on holiday, a project ends, it's December. On its own it told me almost nothing, and I think that's why most health scores end up being decoration nobody trusts.

      What worked better was combinations. Usage sliding and the account going from 4 active users to 1 and renewal coming up in 6 weeks. Any one of those, ignore it. All three, go look.

      The failed payment thing is different though because it's not a prediction at all. Card failed or it didn't. Nothing to infer. That's why I keep going on about it, it's the one clean signal sitting in everyone's Stripe account and nobody looks at it.

      What's your setup, are you building something or just trying to stop the bleeding on your own thing? And what are you using now, if anything?

  2. 1

    I like the distinction between customers deciding to leave and customers accidentally leaving.

    Treating both as "churn" hides two completely different problems. One requires improving the product; the other requires improving the revenue system. That's a much more useful way to think about retention.

    1. 1

      Yeah and the economics are totally different too.

      The accidental ones are the cheapest revenue you'll ever get back. Nothing's broken, they weren't even annoyed, you just have to notice. The deliberate ones mean you've got a product problem and that's months of work.

      So lumping them together isn't just sloppy, it's actively misleading. Your easiest money is hiding inside a number that's telling you to go rebuild your product.

      Do you split them currently or is this more a thing you've been thinking about?

      1. 1

        That's a good question.

        I do have a view on how I'd separate those cases, but I don't think the answer is useful as a generic churn framework. It depends on what signals you're using and what decision you want the system to drive.

        I'd rather explain it in the context of what you're building than reduce it to a few comments.

        If you're interested, what's the best email to reach you on?