DEV Community: zhaochangbo888

I Compared 6 Dunning Tools for Stripe SaaS — and Found a Price Range Nobody Is Covering

zhaochangbo888 — Sat, 19 Sep 2026 13:34:14 +0000

I Compared 6 Dunning Tools for Stripe SaaS — and Found a Price Range Nobody Is Covering

If you run a Stripe-based SaaS between $2K and $10K MRR, you're probably aware that failed payments are silently eating your revenue. You might also be aware that most dunning tools are priced for companies 10x your size.

What I didn't expect, when I started digging into this, is just how wide the gap actually is.

The numbers first

Involuntary churn — payments that fail because a card expired, a bank declined, or funds were insufficient — accounts for 20-40% of total SaaS churn. For SMB SaaS specifically, the monthly involuntary churn rate sits at 0.9-2.0%, roughly double that of enterprise SaaS. A $10K MRR SaaS loses $500-$1,200 per month to preventable churn.

Most of that is recoverable. Stripe's Smart Retries alone recovers about 35% of failed payments. Adding dedicated dunning pushes recovery to 55%+. The problem isn't that recovery is impossible. It's that the tools that do it well are priced for companies that have already figured out product-market fit and have a finance team.

The pricing landscape

Here's what the market looks like right now:

Tool	Price	Model	Setup
Rebill	$19/mo	Flat	2 min
ChurnWard	$29/mo	Flat	5 min
Baremetrics Recover	$58/mo	Flat	10 min
Stunning	$99/mo	Flat	10 min
Churn Buster	$249/mo	Flat	15 min
Paddle Retain	2-4% of recovered	Revenue share	Requires migration

Source: "I Compared 6 Dunning Tools for Stripe SaaS" on DEV, March 2026.

At first glance, $19/mo (Rebill) and $29/mo (ChurnWard) look like they solve the problem for small SaaS. But look closer at what they actually do:

Rebill is the newest player. It offers dunning sequences, expiring card alerts, win-back campaigns, and analytics — full-featured for the price. But it's a single flat tier. If you outgrow $19/mo, your next step is $39/mo for API access and unlimited Stripe accounts.

ChurnWard is minimal by design. It sends dunning emails when payments fail. No analytics dashboard. No custom templates. No expiring card alerts. It's the cheapest option that works, but it's barebones.

The gap: There's nothing between $29 and $58 that offers failure-reason-aware retry logic + SMS channel + expiring card alerts as a cohesive package. ChurnWard at $29 gives you basic email dunning. The next meaningful step up is Baremetrics Recover at $58, which is really an add-on for existing Baremetrics customers and lacks expiring card alerts and win-back campaigns.

Meanwhile, failure reason matters enormously for recovery rate. Here's the breakdown from 2026 benchmark data:

Failure Reason	% of Failures	Recovery Rate
Insufficient funds	35-45%	65-75%
Expired card	20-30%	70-85%
Generic decline	15-20%	50-65%
Bank decline	5-10%	25-40%

Source: Involuntary Churn Benchmarks 2026, SaveMRR.

The top two failure reasons — insufficient funds and expired cards — account for 55-75% of all failures and have the highest recovery rates. But they require fundamentally different recovery strategies. Insufficient funds needs a retry timed to the customer's payday. Expired cards needs a prompt to update the card, not a retry.

Most $29/mo tools treat all failures the same. They send the same email, trigger the same retry, regardless of why the payment failed. That's leaving recovery rate on the table.

What I think is missing

A tool priced at $29-$39/mo that does three things well:

Failure-reason-aware retry scheduling — insufficient funds retries after payday, generic declines retry in 24-48 hours, expired cards trigger a card-update prompt instead of a pointless retry.
SMS as a second channel — email open rates for dunning emails are notoriously low. SMS recovery exists in tools like RecoverPing at $19/mo, but that's SMS-only without the retry intelligence.
Pre-expiry card alerts — Stripe fires a customer.source.expiring webhook 30 days before a card expires. Almost nobody uses it. A simple email on that event recovers revenue before the payment ever fails.

The math for a $10K MRR SaaS: lose $900/mo to involuntary churn, recover 55% instead of the default 35%, and you're adding roughly $180/mo in recovered revenue. At $29/mo, that's a 6x return. At $39/mo, still 4.6x.

My question for this community

I'm considering building this — a $29-$39/mo Stripe dunning tool with failure-reason-aware retries, SMS channel, and pre-expiry alerts, positioned specifically for $2K-$10K MRR SaaS.

If you run a Stripe SaaS in that range: what's your current approach to failed payments? Are you using a tool? Doing nothing? Doing something manual?

And if you've looked at the tools above and decided not to use any of them — what stopped you? Price? Setup complexity? Something else?

I'd rather hear "this gap doesn't exist" now than build something nobody needs.

I Built a Chair Recommendation Tool Using Real Reddit Feedback — Here's What I Learned

zhaochangbo888 — Sat, 25 Jul 2026 13:45:13 +0000

A few months ago, I was stuck in a frustrating loop. My back hurt after long workdays, and I kept buying and returning office chairs that felt fine in the showroom but became unbearable after a week. The problem wasn't the chairs themselves — it was that every "best chair" review out there was written for some generic average person, not for me.

I'm 6'0". My girlfriend is 5'2". We sit completely differently. But all the top‑10 lists and Wirecutter reviews treated us like the same person. So I went down a rabbit hole: I started reading thousands of Reddit comments from real people — short, tall, heavy, light, with back pain, tailbone pain, people who sit cross‑legged, people who recline all day. And it hit me that the best recommendations were already out there. They were just buried in threads.

So I built a tool to organize that chaos. Here's how it works and what I learned along the way.

The data: no scraping, just a lot of reading

I didn't write a scraper or use any API. I just spent weeks reading r/OfficeChairs and r/Ergonomics, collecting real quotes from real users. Every time someone said something like "I'm 5'2 and this chair hurts my thighs after an hour", I added it to a spreadsheet.

Over time, patterns emerged. For example, shorter users almost universally complained about chairs with non‑adjustable seat depth. The Herman Miller Aeron — one of the most recommended chairs on the internet — got a ton of complaints from people under 5'5" because the seat frame digs into their legs.

Taller and heavier users, on the other hand, loved the Aeron. The consensus was shockingly consistent once you filtered by body type.

This spreadsheet eventually became my chair database — about 10 chairs, each with tags for height range, weight range, pain points, sitting styles, and "community sentiment" based on how real people actually felt about them.

The algorithm: hard filters and community sentiment

Instead of a generic "best chair" ranking, I built a recommendation engine with two layers:

Hard filters — these automatically exclude chairs that the community has proven won't work for someone like you. If you're under 5'5" and a chair doesn't have adjustable seat depth, it's out. If you need a headrest and a chair doesn't support one, it's out. No debate.
Community sentiment weighting — for chairs that pass the filters, I score them based on how well they match your specific profile. Height and weight matches get the most weight. Pain point relief gets a big boost. And I add a "community sentiment" score based on what real users with similar body types have said about each chair.

The whole thing runs as a static HTML page. No backend, no database — just a JSON‑like object and some vanilla JavaScript.

The tech stack: boring but intentional

I wanted this tool to be fast, free to run, and easy to maintain. So I went with:

Plain HTML, CSS, and JavaScript — no frameworks, no build step
Cloudflare Pages for hosting — free, global CDN, automatic HTTPS
GitHub for version control — private repo, free
Cloudflare Workers + KV for storing user feedback

The whole site costs me $0/month to run. The only expense was the domain name. For a personal project that might get a few thousand visitors a month, this setup is hard to beat.

Things I got wrong (so far)

I underestimated mobile dropdown menus. On iOS Safari, the native <select> shows a spinner with "Done" and "Cancel" buttons in whatever language your phone is set to. If your phone is in Chinese, the tool showed Chinese prompts. I had to build a custom dropdown component in JavaScript to keep everything in English.
I initially wrote the "About" story like a marketing page. It felt polished and professional — and totally wrong. A friend pointed out it sounded like a startup pitch, not a person sharing a real struggle. I rewrote it in a more casual, first‑person voice, and the feedback immediately improved.
My first attempt at SEO was bad. I had no structured data, no sitemap, no meaningful meta descriptions. Adding JSON‑LD, a sitemap.xml, and fixing the page titles took maybe 30 minutes and made a huge difference in how Google sees the site.

What I'm doing next

The chair tool is live and working. I'm now collecting user feedback (via a simple form that stores responses in Cloudflare KV) to improve the recommendations and add more chairs.

I'm also publishing research notes on the site — basically my raw data‑digging logs, written in a casual notebook style. The first few are about tailbone pain, the Aeron vs Leap debate, and what short users actually recommend. These aren't polished articles; they're messy, honest, and built from real community feedback.

Eventually, I want to apply this same model to other "hard to choose" products — standing desks, pet food, maybe mattresses. The core idea is the same: real people already know what works. The job is just to organize what they've said.

Try it (and tell me what sucks)

The tool is live at truechoose.com. It's completely free, no ads, no sign‑up.

If you try it and something feels off — a bad recommendation, a confusing question, a weird UI quirk — I'd genuinely love to hear about it. This is a one‑person project, and every piece of feedback helps me make it better.

You can also check out my research notes at truechoose.com/notes if you're curious about the raw data behind the recommendations.

Have you built a recommendation tool or worked with messy community data? I'd love to hear your approach — drop a comment below.

I Built an API That Writes Code Documentation in 13 Languages — Here's How

zhaochangbo888 — Sat, 25 Jul 2026 06:05:55 +0000

I’ve always disliked writing documentation. Not because it’s hard, but because it’s repetitive. You write a function, you describe what it does, you give an example, and then you realize you need the same thing in another language because half your users don’t speak English.

So I decided to automate it.

The result is an API that takes source code as input and returns a clean Markdown README, API reference, or inline comments — in any of 13 languages. No templates, no manual translation.

curl -X POST "https://ai-code-documentation-generator.p.rapidapi.com/demo" \
  -H "x-rapidapi-host: ai-code-documentation-generator.p.rapidapi.com" \
  -H "x-rapidapi-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"code":"def add(a,b): return a+b","code_language":"python","doc_language":"en"}'

{
  "success": true,
  "documentation": "# Add Utility\n\n## Overview\nA simple function to add two numbers...",
  "quality_score": 9,
  "target_language": "en"
}

It auto-detects the programming language (Python, JavaScript, Go, Rust…) and spits out a polished doc. The English output is solid, but seeing it generate accurate Japanese or German READMEs from the same code still feels like magic.

The Tech Behind It
Backend: Python + FastAPI, hosted on Northflank.

AI Model: DeepSeek (via API). The model actually understands code structure, so generated docs aren’t just generic wrappers.

Language Detection: Pygments for syntax highlighting + language guessing.

Caching: 24-hour cache to avoid redundant calls and save cost.

Security: Sensitive strings (API keys, passwords) are automatically redacted from the output.

The whole thing is open source:
https://github.com/zhaochangbo888/docgen-api

Why I Didn’t Just Use ChatGPT
You could absolutely paste your code into ChatGPT and ask for docs. But integrating an LLM directly into a CI/CD pipeline, or a VS Code extension, or a platform that needs programmatic access gets messy with rate limits, authentication, and output consistency.

This API gives you a predictable JSON schema, reliable caching, and optional overrides for detail level and format. It’s designed to be called by other tools, not just by humans.

What It Cost Me to Run
DeepSeek’s pricing is absurdly cheap. A 2,000-word README costs less than $0.001. Even with the free tier (50 req/month), I’m not worried about losing money while people test it.

Try It Yourself
There’s a demo endpoint with no subscription required (5 requests/day). Just grab a free RapidAPI key and start playing:

👉 https://rapidapi.com/zhaochangbo0/api/ai-code-documentation-generator

Plans:

Free: 50 requests/month

Basic: $9.99/month for 5,000 requests

Pro: $49/month for 50,000 requests

All plans include all 13 languages and all doc formats (readme, api_doc, inline comments).

What I’d Love Feedback On
I’m actively improving the output quality. If you try it on your own code, let me know:

Does the generated doc actually save you time?

What languages or doc formats are missing?

Does the quality hold up for larger, real-world codebases?

Drop a comment or open an issue on GitHub. I’ll be hanging out in the replies.