your revenue is leaking. this catches it.
most SaaS founders know their churn rate.
very few can answer a simpler question:
"how much of this churn was people choosing to leave vs payments silently failing?"
stripe already knows that answer.
most dashboards don't.
the part of churn you never see
when churn goes up, the default story is:
“users didn’t get enough value” or “onboarding isn’t good enough.”
but a non‑trivial slice of churn is just:
cards expiring
banks declining
retries failing in the background
subscriptions cancelling after the last attempt
no feedback form. no angry email. just subscriptions quietly dropping out of the bottom of stripe.
same number on your churn chart, completely different problem to solve.
stripe is already raising its hand
out of the box, stripe fires events like:
invoice.payment_failed— payment failed, short window to recover itcustomer.subscription.updated— plan change, including downgradescustomer.subscription.trial_will_end— trial about to endpayment_method.detached— card removed
these are basically leak signals.
the issue isn’t that the data doesn’t exist — it’s that it lives in logs and webhooks instead of in the place most founders look every day.
after ~30 days, even that history starts to fade.
why i'm building recurflux
i’m building recurflux because i want one simple thing as a founder:
instead of “churn was 6.2% this month,”
i want:
“this much was failed payments that could have been recovered,”
“this much was downgrades that turned into cancels,”
“these trials died without a single touch.”
recurflux connects to stripe and:
pulls in as much historical data as the api allows,
listens to webhooks going forward,
groups events by customer and subscription so you can see the actual story, not just the outcome.
the goal is not magic retention. it’s visibility: a map of where money is leaking so you can decide how to patch it.
why i think it should pay for itself
recovering a single failed payment at $79/month is $948/year.
if a tool that watches for these leaks costs less than that, it doesn’t need to be a miracle — it just needs to help you notice and save a few of the payments you were already supposed to get.
that’s the bar i’m trying to hit with recurflux.
if yoy want to see your leaks
stripe integration is live and i’m onboarding early teams now.
if you’re running a subscription product on stripe and you don’t have a clear breakdown of:
involuntary vs voluntary churn
how much sits in retries
how downgrades lead into cancellations
you can plug in your account and see what falls out.
if recurflux doesn’t surface at least one meaningful leak or opportunity to save revenue, it’s not doing its job — and you’ll know that quickly.
join here: https://recurflux.com/
The problem they solve is very important, but given the prices they charge, it will only be useful for those already well-established in the market. For those who want this tool and are still starting out, it would be better to charge a percentage of the recovered amount; that would be fairer for everyone. But nowadays, what's fair doesn't matter; as long as it works, that's already very good. Good luck on the rest of your journey...
Fair feedback, thank you.
percentage-based pricing makes sense for early-stage teams, but adds complexity around tracking and attribution. we're thinking through it.
if pricing is blocking you but you'd benefit from recurflux, reach out — happy to work something out that fits your stage.
"Spot on. So many founders mistake involuntary payment failures for voluntary churn. Building a dashboard that exposes these exact leaks directly from Stripe webhooks is a smart move that easily pays for itself. Best of luck with the early onboarding for Recurflux!"
appreciate that, thank you.
the moment you split those two, the fixes become way more obvious. would love to hear what you're building if you're tackling this space too.
Your "$52k MRR modeled scenario" in the social proof section reads as fabricated data to skeptical founders — modeled projections framed as outcomes signal that there are no real customers yet, which is the opposite of what that section is supposed to do. Swapping that with even one specific result from a beta user, however small, would instantly change how the page lands. Happy to record a free 5-min Loom audit showing where the trust breaks down and what to replace it with. — Ramin, Convertly
This is really valuable feedback, thank you for calling it out.
you're absolutely right that "modeled scenario" reads wrong in that section — it undermines credibility instead of building it. taking a hard look at that whole block now. appreciate the direct feedback.
Congrats on your launch
Nicely done! A very professional and appealing website, and a compelling solution to an overlooked problem.
Really appreciate that, thank you for checking it out.
This whole "silent churn" layer is overlooked by a lot of us, so it means a lot that the problem and the site both came through clearly.
Very welcome. I'm building a platform to make it much easier for builders to include SMS into their apps. Just by way of research (not trying to sell you, I'm a few months out from being able to offer this), if adding an SMS offering to your service would be an attractive angle. Say, if you could offer a way for your customers to add a "text me if I have a payments issue" phone number field to their app. It's relaykit.ai. Thanks.
This is a real pain point. Most founders I know are surprised when they dig into how much of their churn is actually failed payments vs genuine cancellations. The framing of 'involuntary vs voluntary churn' is exactly the right way to think about it. Building something similar for Next.js + Supabase stacks – the infrastructure problems are always more invisible than the product ones.
This is exactly it – the moment you draw that involuntary vs voluntary line, you realize you’ve been solving the wrong problem half the time.
your next.js + supabase approach sounds spot on; infra pain is always invisible until you’ve already paid the price. happy to compare notes anytime.
100% agree – the infra tax is brutal especially early on. That's exactly why I built a Next.js + Supabase starter kit to skip all that setup. Would love your feedback as someone who clearly gets the problem.
The involuntary-churn slice is usually 20-40% of total churn for SaaS at low ticket sizes, and Stripe's Smart Retries + an account_updater subscription on the customer recover most of it before you need a custom dunning flow. One thing worth wiring alongside invoice.payment_failed: listen for customer.source.expiring (30 days before a card expires) and email the user a one-click update link — prevents the failure rather than recovering from it, and it's the single highest-ROI webhook I've added.
Really good insight on customer.source.expiring — preventing the failure beats recovering from it every time.
we've built recurflux to catch and surface these signals (expirations, failed payments, downgrades) before they become problems. if you ever want to plug your stripe data in and see how it maps across your flow, happy to onboard you and compare what we're both seeing.