We built Recurflux for RevenueCat users because the gap was just too obvious to ignore.
we built Recurflux for RevenueCat users because the gap was just too obvious to ignore.
every churn recovery tool out there is built for Stripe. we kept running into RevenueCat founders during research who had zero purpose-built options for involuntary churn. not because the problem was hard, just because nobody had shown up for them yet.
so we did.
we were already building Recurflux for Stripe users. payment recovery, dunning sequences, the whole thing. and while doing customer research we kept bumping into the same type of founder over and over again.
mobile app. subscription product. RevenueCat stack. involuntary churn quietly eating their MRR. and zero purpose-built options available to them.
not because the problem is unsolvable. because nobody had bothered to show up for this specific group of people.
every tool in this category assumes you're on Stripe. they hook into card vaults, retry logic, processor APIs. RevenueCat doesn't expose those things the same way, so the tools never bothered supporting it properly.
the result is thousands of mobile SaaS founders either building clunky Zapier workarounds, sending manual emails, or just accepting a baseline of monthly churn they've decided to live with.
we thought that was a solvable problem. so we tried to solve it.
——
here's what we built and what we didn't, and why.
we built smart dunning sequences that email your at-risk subscribers when a payment fails, day 1, 3, 7 on Rise and all the way to day 30 with 6 touchpoints on Surge. branded emails from your domain, your logo, your sender name. win-back sequences for users who already churned. subscription pause flows that are fully compliant with Apple and Google Play. a proper dashboard so you can actually see what's happening. SMS dunning, A/B testing, Slack alerts on Surge.
what we didn't build: smart retries, card health monitoring, dispute management.
not because we didn't want to. because RevenueCat doesn't expose the billing layer in a way that lets us do it. Stripe tools can hook into retry logic and card data directly. we can't do that on RevenueCat. so we don't pretend we can.
that's the whole story.
no drama. no big moment. just a gap that existed, a group of founders being ignored, and us deciding to do something about it.
if you're on RevenueCat and involuntary churn is quietly bleeding your MRR, give it a shot.
get your ROI and i assurte you will be glad clicking it : "https://recurflux.com/resources/revenuecat-churn-calculator "
and if you've been patching this problem with duct tape solutions, drop a comment. genuinely curious what workarounds people have been using.
The "obvious gap" framing is interesting — were you guys RevenueCat users first who hit that wall yourselves?
Not RC users ourselves. We started on Stripe and ran a lot of research interviews. RC founders kept showing up with the exact same problem and zero good options. After the 15th conversation sounding identical it stopped feeling like a coincidence and started feeling like a gap worth filling.
This focus on RevenueCat is very smart. Most tools assume everyone lives in Stripe-land, but mobile developers have totally different headaches. I’ve seen so many founders trying to "duct tape" their churn recovery with messy Zapier flows and manual emails—it is such a time sink.
Addressing a gap that others ignored just because it was "too niche" is exactly how great products start. I am glad someone finally showed up for the mobile SaaS crowd. Great job on the launch!
The Zapier thing came up constantly in research. Someone would walk through their setup and you could hear the exhaustion in it. Four zaps, a Google Sheet acting as the database, manual emails going out every Monday morning. It works until one zap breaks on a Friday night and you're debugging it instead of building. That's the real cost nobody talks about.
The section listing what you didn't build does more than build trust. It also self-qualifies the buyer. A mobile founder reads about missing smart retries and either nods because dunning is the priority, or bounces because retries come first. Either way you skip a bad-fit conversation before sales work happens. Most founders treat the constraint disclosure as a weakness. It's actually one of the highest-leverage parts of the page, the only thing that filters who continues and who doesn't before they hit pricing.
That's exactly the intent behind it. If you can't do smart retries because the billing layer doesn't expose it, saying so upfront filters out the founder who needs that first. Better they find out on the page than on a sales call. Honestly it took a bit to get comfortable publishing that section, feels counterintuitive to list what you can't do. But the alternative is wasting everyone's time.
The 'nobody bothered to show up for them' framing is textbook narrow wedge, and it's the right call. The honest 'what we didn't build and why' section is actually your strongest pitch, because founders who admit constraints inspire more trust than ones who pretend they can do everything. One thing worth pressuring on: involuntary churn in mobile SaaS behaves differently than Stripe SaaS because card-on-file lives with Apple and Google. The recoverable share via dunning emails is often smaller than founders expect, while subscription pause and win-back flows tend to carry more of the lift. If you can publish a real benchmark like 'recovered involuntary churn percent by sequence type' from your first 20 customers, that becomes an unfair distribution asset for you. Nobody else is positioned to produce that data.
This is the right pressure to apply and I think you're correct. The recoverable share via dunning alone is smaller here than most Stripe-side benchmarks suggest, because you can't touch the card. What we can move is the behavior - pause instead of cancel, win-back after churn. That's where the real lift comes from on mobile. The benchmark idea is something we're actively working toward.
genuine question: how are you handling the Apple and Google Play compliance piece in practice? subscription pause flows sounds straightforward but both stores have gotten weird about what's allowed in win-back flows specifically. did you have to get anything reviewed or is it just following the published guidelines and hoping for the best? asking because that's the part i've seen trip people up
Good stuff. I think the biggest takeaway here is that most founders spend too long building before validating distribution. How long did it take you to find your first paying customer?
Solid advice on bootstrapping! The lean approach really does force creative solutions. For anyone hunting for their first customers, I'd recommend trying targeted outreach - it's slower but higher conversion. And if you need help finding the right people to reach out to, Rixly uses AI to identify and validate prospects based on their actual needs.
Solid advice on bootstrapping! The lean approach really does force creative solutions. For anyone hunting for their first customers, I'd recommend trying targeted outreach - it's slower but higher conversion. And if you need help finding the right people to reach out to, Rixly uses AI to identify and validate prospects based on their actual needs.
Agreed on targeted outreach — the conversion difference versus broad blasting is real. What's worked better for us is targeting by stage rather than intent signals. Founders at the right MRR have the problem whether or not they've posted about it.
I really appreciate the 'what we didn't build' section. It’s rare to see a founder being so upfront about technical limitations (like the lack of decline codes from RC). That transparency actually builds way more trust than a generic 'we solve everything' landing page. Solving the email/dunning layer first is a very smart move for the RevenueCat ecosystem.
The decline code gap was the thing I almost didn't put in. Felt like admitting a weakness upfront. But hiding it would've just meant a frustrated founder hits it on day 3 and loses trust anyway. Better to say it clearly and let them decide.
Love this approach — building around the actual limits of RevenueCat instead of pretending everything works perfectly builds way more trust.
A lot of founders underestimate how much involuntary churn quietly hurts until they finally track it properly.
The tracking part is what shifts the whole mental model. Most founders I talk to only discover how much involuntary churn they have when they actually look at 90 days of payment history, before that it just reads as churn because the subscription expired either way. The silent part is what makes it expensive: no cancel event, no reason survey, just a card that quietly failed and a customer who disappeared without deciding to leave.
This makes sense. I like that you picked a very specific gap instead of trying to build a general subscription recovery tool.
The RevenueCat angle is clear, and the pain sounds real: failed payments, involuntary churn, and founders losing MRR without having a proper recovery flow.
One thing I’d be curious about is how you plan to position it long term — only for RevenueCat users, or as a wider mobile subscription recovery tool later?
RC is the first wedge because the gap is most acute there, mobile founders on App Store/Play Store billing have almost no tooling built for them. Stripe founders at least have Churnbuster, Stunning, Churnkey. RC founders are mostly handling this manually or not at all.
But Recurflux already supports Stripe, Paddle, and Razorpay alongside RC. The long-term position isn't "RevenueCat tool", it's subscription recovery for founders who don't have a billing engineer and can't afford to find out what's wrong six months later when the MRR chart tells them. RC is where version 1 solves the problem most clearly. Wider mobile follows once the App Store/Play Store recovery layer is solid.
That makes sense. RevenueCat as the first wedge feels smart because the pain is sharper and easier to explain.
I also like the wider angle: subscription recovery for founders who don’t have a billing engineer.
The “MRR chart tells them six months later” line is strong. I’d bring that higher in the messaging.
Moving it up this week. Appreciate the push on that, it's been buried in the positioning when it's actually the sharpest line in it.
Hello sir,
I came across Recurflux on Indie Hackers and I genuinely think what you’re building is smart.
Most founders ignore niche pain points because they’re not “big enough,” but you spotted something real with RevenueCat churn recovery. The positioning alone is strong because you’re speaking directly to a group that’s been overlooked for years.
I actually think there’s a big opportunity to build a loyal founder community around this. A lot of mobile SaaS founders are silently dealing with churn and duct-taping solutions together, so content, onboarding, customer conversations, and community engagement could become a serious growth channel for you.
I work as a Community Manager & Virtual Assistant, helping startups stay close to users, manage conversations, improve engagement, handle outreach/support, and create a smoother experience for customers while founders stay focused on product.
I’d love to support Recurflux however I can — whether that’s community management, founder outreach, customer support, onboarding, content coordination, or day-to-day operational help.
Either way, really solid product direction. Rooting for you guys.
This comment was deleted a month ago.