Let me start with the number everyone actually wants to see: $0.
No MRR. No users. No waitlist of thousands. Just a product that went live this week and a Twitter thread I'm hoping doesn't flop.
I'm writing this because most launch posts are either "we hit $10K MRR in 3 months!" retrospectives or fake-humble brags. This one's a live diary. The outcome isn't determined yet.
What I built
Revive — automated payment recovery for SaaS on Stripe.
The problem it solves: involuntary churn. That's when customers don't choose to leave — their payment just fails and nobody catches it in time. Industry data puts this at roughly 9% of MRR for the average SaaS. Most founders chalk it up to "customers churned" and move on.
They didn't churn. Stripe just retried at the wrong time and gave up.
Revive connects to Stripe, watches for failed payments, applies a smarter retry schedule based on why the payment failed (insufficient funds vs. expired card vs. do-not-honor are very different problems), and sends dunning emails that are timed to when people actually open and act on them.
Setup is genuinely 5 minutes. I've timed it.
Why I built this
Honestly? I was analyzing Stripe data for another project and the failure patterns were jarring.
The default Stripe retry logic was built for a world where most cards fail for the same reason. They don't. Failed payments cluster differently by card type, issuer, time of month, and failure code. The optimal retry window for "insufficient_funds" is usually right after the 1st or 15th (payday). A declined "do_not_honor" usually needs a fresh manual intervention, not an automated retry at 3pm on a Tuesday.
Nobody was building for this granularity at an indie-accessible price point. Enterprise tools exist (Churnkey, Stunning) — they're good but expensive and feel enterprise-y. The free tier of Stripe's own Smart Retries is too generic.
So I built what I wanted to use.
How I actually built it
This is where it gets interesting, or embarrassing, depending on your perspective.
I used AI agents for most of the infrastructure build. Not Copilot autocomplete — actual agent loops that designed and implemented:
- The retry scheduling engine (calculates optimal retry windows per failure code)
- Stripe webhook ingestion + idempotency handling
- Email queue with exponential backoff on delivery failures
- The dunning email templates (3 stages: gentle reminder → urgency → final notice)
I reviewed, tested, and iterated on everything. But the velocity was unlike anything I've shipped before. From zero to working Stripe integration was days, not weeks.
The architecture is boring on purpose: Node.js, PostgreSQL, BullMQ for job queues, Resend for email. Nothing clever. Clever infrastructure is how you spend 3 months debugging race conditions instead of talking to customers.
What's different about Revive vs. the alternatives
Churnkey / Stunning: Both excellent. Both cost $300–$500+/mo to get meaningful features. Built for funded SaaS with 100+ customers already.
Stripe Smart Retries (built-in): Good baseline. Doesn't do dunning emails. Doesn't segment by failure reason. No analytics.
Revive: Free up to $500/mo recovered. $99/mo for unlimited. Retry logic that accounts for failure reason. Dunning emails that go out on a schedule that matches how people actually behave with their cards.
I'm not claiming to be better than Churnkey on every dimension. I'm claiming to be the right tool if you're doing $5K–$50K MRR and want something that works without an enterprise sales call.
The honest questions I don't have answers to yet
- Will the retry timing improvements actually show measurable lift vs. Stripe's defaults? (I believe yes based on the data I analyzed, but I need real customer data to prove it.)
- Is $99/mo the right price? No idea. First 10 customers are getting 3 months free so I can get signal before I stress about pricing.
- Will anyone care about the "built with AI agents" angle or is that noise? Probably noise for buyers, interesting for builders.
What I'm doing next
Soft launch this week. Watching the metrics. Talking to anyone who tries it.
Product Hunt launch in the next few weeks — will post when it's live.
If you're running a SaaS on Stripe and want to be an early user (free, no strings), drop a comment or DM. I'll set you up personally and bug you for feedback.
Revenue update coming in 30 days. Something or nothing — I'll post it either way.
🧙♂️
What I Built (and How to Try It)
Read the full technical breakdown:
- 🔧 Stripe Failed Payment Recovery: The Complete Playbook — everything I learned about dunning strategy
- 📈 How FormDraft Recovered $2,400/Year — a real-world example of Revive in action
- ⚙️ Revive Demo Walkthrough — recover your first failed payment in 5 minutes
Try Revive: revive-hq.com
Top comments (2)
Really appreciate the honesty here — the $0 MRR reality check is refreshing compared to the usual "we hit $10K in week 2" posts.
Your point about "boring architecture on purpose" — couldn't agree more. I'm running a Telegram Mini App on the exact same core: Node.js + PostgreSQL + nothing clever. Spent zero time debugging infrastructure issues, all the time went into the actual product and talking to users.
Two things resonated hard:
Failure code granularity matters. We see the same pattern with Telegram Stars payments — different failure modes need different handling. The
pre_checkout_queryin Telegram has a brutal 10-second timeout, and if you try to do too much logic there, the payment just silently dies. Similar to how Stripe retries at the wrong time — the timing and context of the recovery attempt is everything.The "building in public, $0" phase. I launched with $0 in revenue for weeks. What changed was removing friction from the payment flow — went from planned Stripe integration to native Telegram Stars (2 taps, no card entry). Conversion jumped because the payment matched the context. For your tool, the "5 minute setup" pitch is the equivalent — reducing friction to try it.
The AI agent workflow for infrastructure is real. I had a similar experience building the payment + referral system — what would have been 2 weeks was done in days. The output still needs human review, but the velocity is transformative once you learn the prompting patterns.
Curious: are you considering offering a free tier that just surfaces the analytics (why payments fail) without the automated recovery? That alone would be valuable enough to get people integrated, and the upsell to "now fix it automatically" seems natural.
The boring architecture observation is real — I had two weeks of Convex experimentation that taught me nothing except that Supabase + Node would have shipped faster.
The pre_checkout_query timeout analogy is spot on. That 10-second window is basically the Stripe insufficient_funds scenario — the retry context matters as much as the retry itself.
On the free analytics tier: yes, that's exactly where I'm leaning. The "why your payments fail" dashboard as a free hook, then "let us fix it automatically" as the paid layer. You've basically described the conversion funnel I'm testing with the first 10 users. The friction reduction argument is the same one that got me to drop the "please integrate our webhook" onboarding for a one-click Stripe Connect flow.
Curious what your user retention looks like on the Telegram Mini App — native payments eliminating card friction is interesting data for my own "what kills the conversion" research.