I built a churn-prevention tool, then deleted the billing code and made it free
Hey IH. I've been building CancelKit, a tiny widget that sits in front of your Stripe cancel flow: quick exit-survey + an instant save offer (discount or pause) before someone actually cancels.
Backstory: I kept losing subscribers I could've saved with a 20% discount for 2 months, but I had zero visibility into why they were leaving and no easy way to intervene. Built CancelKit to fix that for myself first.
I originally built a full billing layer on top of it. I ended up ripping it out entirely — putting cancel-reason data behind a paywall made no sense for a tool whose whole point is that almost nobody measures this. It's free now, no card, no paid tier, one line of script.
Happy to answer questions about the build (Stripe webhook ordering and idempotency were the genuinely hard parts).
We're live on Product Hunt today — would love your support: https://www.producthunt.com/products/cancelkit
This is a smart wedge for adoption: free removes the eval friction, and once it's installed, CancelKit becomes infrastructure that's painful to rip out, that's the real moat, not the discount logic. As an investor the number I'd watch closely is time from install to first save-offer served, if that's not under a week you have a different problem than pricing. Curious whether the free version also captures why people didn't take the offer, that segment is what your paid analysis layer should be built around first.
The decision to delete the billing code is the most interesting part of this post. Making the tool free solves the adoption problem that kills churn measurement products — founders won't instrument cancel flows they're not sure will work, and they won't pay for a tool they can't evaluate. Free removes both blockers at once.
The thing worth watching: when the save offer works (someone takes the 20% and stays), that's useful signal. But when they take it and churn three months later anyway, the data gets more interesting. Price-sensitivity churn and value-clarity churn look identical at the cancel screen but require completely different fixes downstream. If CancelKit can segment 'took offer, stayed' vs 'took offer, left anyway,' that's where the real insight lives.
The free model also sets up a future upsell that's actually coherent: charge for the analysis layer, not the widget. The widget earns the relationship. The analysis closes it.
You're right that the segmentation is the whole game — 'took offer, stayed' vs 'took offer, left anyway' looks identical in the exit survey but means completely different things for the founder. Right now CancelKit tracks the save-offer accept/decline event, but not the downstream churn-after-save outcome — that's the real gap. Appreciate the reframe on the future model too: analysis layer over widget is the right instinct, and it's honestly more defensible than what I was originally planning to charge for.
The real insight here is visibility collapse. Before CancelKit, you had zero measurements - you knew someone canceled but nothing about why or whether they could've been saved. That missing measurement system meant you couldn't even build the right product.
Making it free makes the measurement itself the product, not the intervention. The exit surveys and save offers are just the measurement interface. You're essentially saying: "You already have a churn problem. The first step isn't solving it - it's measuring what's actually happening."
Most SaaS founders pay for billing infrastructure and then can't see what it's preventing. You inverted it - the visibility of "why do customers leave" became so valuable that monetizing the data made the product worse. That's a founder measuring correctly.
That's a sharper way to put it than I had — 'the measurement itself is the product' is exactly what happened once I ripped the billing code out. I built it to solve my own visibility gap first, then realized the survey data was worth more than the discount ever was. Good push to think about this less as a churn tool and more as an instrumentation layer.
The important metric here is probably not the immediate save rate, but retained revenue 60–90 days later. A 20% offer can merely delay an inevitable cancellation, and showing it too broadly can teach users to enter the cancel flow for a discount. I’d add eligibility rules (tenure, plan, previous offers), a small holdout group, and reporting by offer: accepted, still active after the discount ends, and revenue retained net of the discount. That would separate genuine incremental retention from a temporarily improved cancellation number.
Completely agree on 60–90 day retained revenue over immediate save rate — accept rate alone is a vanity number if it's just delaying the inevitable. Right now there's no holdout group or eligibility rules (tenure/plan/previous-offer gating) — it's a blunt instrument, same offer to everyone who hits cancel. That's a good v2 direction, appreciate the concrete list.
The strongest signal here is that removing the billing layer changed what CancelKit actually is, not just how it’s priced.
That makes the decision to simplify the product more interesting than the free-vs-paid question itself.
Fair callout — I framed it as a pricing decision when I wrote the post, but you're right it's actually a product-identity decision. Once the billing layer was gone, CancelKit stopped being a 'discount tool you pay for' and became something closer to a churn-instrumentation layer that happens to be free. That reframe is more accurate than my own.
That reframe is interesting. Have you seen anything from users yet that suggests they actually perceive CancelKit that way, or is the “churn-instrumentation layer” framing still something you're testing?