DunningKit

Last year I had a problem I didn't know I had.

I was checking Stripe one morning and noticed something that didn't add up. Revenue was roughly flat month-over-month, but I had more active users than the previous month. The math was off. I started clicking through individual subscriptions and found a graveyard of "past due" accounts, people who were actively using the product, logging in regularly, getting value. Their payment had just quietly failed, Stripe sent one generic email, nothing happened, and they stayed in limbo until the subscription finally canceled.

I added it up. $3,200 in MRR sitting in failed-payment purgatory. A chunk of it recoverable if someone - or something - had followed up properly.

That was the moment I realized involuntary churn is a completely different problem from regular churn, and most of the tooling for it is either expensive, takes a cut of recovered revenue (insane), or is just Stripe's built-in retry with a template email slapped on.

So I spent the next few months building DunningKit.

What it does

When a payment fails on your connected Stripe account, DunningKit kicks off a recovery sequence:

1. Smart retry scheduling Configurable per campaign. Day 1, 3, 7, 14 by default. Different failure reasons (insufficient funds vs. card expired vs. do_not_honor) respond differently to retry timing. You set the logic, DunningKit runs it.

2. AI-personalized recovery emails This is the part that actually moves conversion rates. I'm using Gemini 2.0 Flash to generate each email with real customer context: their name, what they're subscribed to, the amount, why the card failed, how many retries have already run. The output is genuinely different per customer , not a {first_name} template.

3. Hosted payment update page HMAC-signed tokenized link, no login required, works on mobile. Customer clicks, updates card, done. The recovery registers in Stripe automatically.

4. Analytics Recovery rate, revenue recovered vs. at-risk, email open/click rates, retry success by day. Enough to actually tune your strategy.

The stack, for those who care about that stuff

Next.js 15 App Router, Neon Postgres, Drizzle ORM, Clerk, Resend, Stripe Connect, Vercel. All force-dynamic routes. Stripe clients lazy-initialized inside handlers (learned that one the hard way during build). Encryption tokens use AES-256-GCM. Payment update links use HMAC-SHA256 with expiry.

Built it solo over a few months, mostly evenings. Zero external funding, no team yet.

The pricing decision I went back and forth on the most

Most dunning tools charge a percentage of recovered revenue. I understand the logic, aligns incentives, easy pitch. But it bothered me philosophically. You already acquired the customer. You already built the product. You already delivered value. Why should you pay a percentage tax on getting your own money back?

I went flat-rate SaaS instead. Starter, Pro, Agency tiers. No revenue share. The math is more predictable for the customer and more honest about what the product actually is.

What's working, what isn't

Working:

• The AI email layer. Early users have commented that the emails don't read like automated billing notices, they read like something a real person would send. That's the goal.

• Multi-account Stripe Connect. Agencies managing multiple clients seem to genuinely want this.

• Setup time. Median time from landing page to first campaign live is under 10 minutes.

Not working / still figuring out:

• Distribution. I can build the product. Getting it in front of the right people (SaaS founders with Stripe subscriptions) is the current hard problem.

• Positioning. "Dunning tool" means nothing to a lot of founders. "Recover failed Stripe payments" lands better. Still testing.

• The pricing page was hardcoded for way too long — just fixed it so it pulls live from the admin config. Should have done that from day one.

The number I'm watching

Recovery rate. Not MRR yet, too early to have meaningful data. But for every user who connects a Stripe account, I want to know: of the payments that failed and went through DunningKit's sequence, what percentage recovered? That's the number the product lives and dies on.

Current early signals are promising. More data needed.

Questions I genuinely want answered

If you're running a subscription SaaS:

1. What's your current failed payment process? Stripe native retries + smart retries? Manual follow-up? Nothing? I want to understand what people are actually doing before they find a tool like this.

2. Would you pay for this on a flat-rate model, or does revenue-share actually feel safer to you? (Genuinely curious — I might be wrong about this.)

3. What would make you nervous about connecting a third-party tool to your Stripe account? Security? Data access scope? I want to address real concerns, not assumed ones.

Site is live at dunningkit.com. Starter plan is free to try. Happy to give IH folks early access to Pro features in exchange for honest feedback — drop a comment or DM me.

Building in public from here. Will post numbers when there are numbers worth posting.

— Founder, DunningKit