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?
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 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.
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.
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.
The Stripe-vs-RevenueCat asymmetry is real and it's nice to see someone fill it. As a solo dev building a small iOS memo app (a Captio-style replacement), I've been lurking in mobile founder Slack groups and "I think churn is around 10–12% but I genuinely can't tell how much is involuntary" comes up almost weekly. The Apple/Google billing layer being opaque is probably the single biggest reason mobile founders under-invest in dunning compared to web SaaS.
One thing I'd be curious about: how do you separate "card declined / locked region" from "genuinely changed their mind" in the dashboard view? On Stripe you can lean on retry signal, but on RC you only get a webhook and then silence. Is that surfaced as a confidence score, or left ambiguous for the founder to interpret?
Apple and Google own the billing layer, so RC doesn't expose the underlying decline code. You can't separate "locked region" from "genuinely changed their mind" the way you'd separate insufficient_funds from do_not_honor on Stripe, that signal doesn't exist.
What Recurflux surfaces instead: behavioral signals after the BILLING_ISSUE event. Did they open the dunning email? Did the grace period extend? Did they cancel within 48 hours of the billing issue, or just go quiet? Those three together bucket into "likely involuntary — billing issue, no action taken" vs. "likely voluntary — billing issue followed by cancellation." Not a confidence score. Two buckets, you make the call, but you're not manually digging through RC's event log to get there.
For a 10–12% churn rate, that split matters a lot. If 4% of that is billing failures there's a known fix. If 9% is genuine cancellation the problem is somewhere else entirely.
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 is a strong wedge because you’re not trying to beat every Stripe dunning tool head-on. You found a neglected stack-specific segment where the pain is real, the workaround behavior already exists, and the buyer can calculate lost MRR quickly.
The sharper positioning may be less “RevenueCat churn recovery” and more “revenue recovery infrastructure for mobile subscription founders.” That gives you room to stay specific now without making the brand feel trapped inside one integration forever.
Recurflux explains the function, but it also sounds very billing-tool-specific. If this expands into broader mobile subscription retention, recovery, and revenue workflows, a cleaner SaaS name like Beryxa .com may age better as the umbrella brand.