Long-time lurker, now building
Been reading IH for years. Never posted.
Kept seeing the same thread from SaaS founders on Stripe: losing MRR to failed payments, not sure what to do about it. The advice was always about sending better dunning emails or setting up smarter retries.
Something about that always felt off to me. Those are action tools. But the founders asking didn't sound like they had an action problem — they had a seeing problem. They didn't know which failures actually mattered or which customers were worth chasing.
I sat on this for a while. Classic lurker you see!
Eventually started building. Working name is tryrecoup. It's a revenue intelligence layer for Stripe — not a dunning tool, not a retry engine. Just answers one question: of the money at risk in your Stripe account, what matters and what's recoverable?
Going to post here weekly as I build it — one feature, one decision, one mistake at a time. Trying to:
- Ship publicly instead of tweaking in private for months
- Get feedback from founders who actually feel this
- Find 5 design partners on Stripe to shape where it goes
If you're on Stripe and this resonates, reply or DM. I'll add you to a small list of early testers.
The design-partner approach makes sense. One thing I'd get right early is keeping Stripe state and your app's own state clearly separated — especially once you start handling retries, failed payments and events arriving out of order. Otherwise you can end up debugging whether Stripe, the webhook handler or your own DB is actually wrong.
Thanks. That's really good advice.
The “seeing problem” distinction is interesting. With your first Stripe users, are you finding that founders change who they chase or how they prioritize recovery once they can see the recoverable amount, or do they mostly want the tool to take the recovery action itself?