Build vs. Buy Dunning: The Decision Every SaaS Team Gets Wrong

For most subscription businesses, buying a dunning tool beats building one once monthly recurring revenue (MRR) passes about $50k, based on our analysis. A compliant retry system costs more in engineering hours than the tool does.

Most DIY builds carry at least one silent failure mode that stops retries with no error.

From the subscription businesses I've helped, the teams that recover the most aren't running the most aggressive retry schedules. They treat dunning as a customer-communication and compliance job, which is exactly the part a DIY build underestimates.

This guide shows you how to decide in under 30 minutes.

Key takeaways

• Buy a dunning tool once monthly recurring revenue passes about $50k.
• Budget 40-80 engineering hours plus quarterly upkeep to build a compliant retry system.
• Expect $200-500 a month for a tool that recovers more than it costs.
• Audit your recovery rate, because DIY builds often stop retries silently with no error.
• Build only for a non-standard billing model or under $10k monthly recurring revenue.

Should you build or buy your dunning system?

At $50k or more in monthly recurring revenue, buying usually wins, based on our analysis. The tool starts paying you back in month one, while a build takes until the following quarter to break even.

Three revenue bands sort the decision, and the rubric below settles the middle band with your own numbers. Above $50k MRR, buy, based on our analysis. Below $10k MRR, build or lean on native recovery, based on our analysis.

The $10k to $50k MRR middle depends on your involuntary churn rate.

Three inputs decide where you land in that middle band:

1. How much revenue you're losing to involuntary churn, the subscribers who leave on a failed payment rather than a decision to cancel.
2. The engineering hours your team spends building the retry logic and keeping it compliant as card network rules change.
3. Whether your billing platform's built-in recovery already covers your gap, which the dunning guide covers in full.

Revenue isn't the only reason to build, though.

Two situations call for a build at any size. One, your billing is genuinely non-standard, like usage-based charges blended with subscriptions behind custom retry gates. The other, your compliance team requires payment data to stay on your own servers.

What DIY dunning builders get wrong

Most teams that build their own dunning introduce at least one silent failure mode that stops retries without firing an error. They don't catch it until they audit recovery rates months later, because the build looks finished and payments still process.

Nothing in the logs says recovery quietly fell to zero for a slice of subscribers.

Dunning looks like a billing task, but it behaves like a state machine wired to your customer emails and to card network rules. Three failure modes cause most of the breakages, and each one gets its own section below.

The silent 200-OK trap

When your webhook returns 200 OK while your own code cancels the subscription, Stripe reads collection as complete and stops Smart Retries with no error. No alert fires. Recovery drops to zero for every subscriber who hits that path, and the dashboard still looks healthy.

Your handler tells Stripe it received the failed-payment event by sending a 200, which is correct. But the same code sets the subscription to cancel internally, and a canceled subscription tells Stripe to stop trying to collect.

Smart Retries still had attempts scheduled, and the cancellation pulls them off the queue. From Stripe's side everything is consistent, which is exactly why nothing complains.

This one is specific to building custom logic on top of Stripe Billing. Chargebee's and Recurly's native retry engines keep the state machine inside the tool. Teams on those platforms stay clear of it, because their code never touches the cancellation path.

The hosted_invoice_url expiry problem

Stripe's hosted_invoice_url, the card-update link in your dunning emails, expires 30 days after the invoice due date.

A subscriber who clicks a recovery email a month later lands on a dead page instead of a payment form. The email reads fine the day it sends and then fails quietly for anyone who waits.

This bites hardest when you stretch the retry window to chase slow payers. The longer you wait for a card to clear, the more of your dunning emails point at a link that's already gone. The subscriber who finally decides to pay can't, and you never see the abandoned attempt.

A DIY build has to refresh that link itself before each email, and most don't.

Card network retry-limit violations

Retry a failed charge too many times and you break Visa and Mastercard rules, which trigger per-attempt fees and a penalty flag on your merchant account.

The networks cap how often you can retry one declined payment, so a hand-built cadence that ignores the cap turns a recovery attempt into a compliance problem.

A DIY scheduler that retries on a fixed calendar has no idea why a card declined or how many attempts the network allows. It just keeps firing.

The fix is to read the decline code and stop when the rule says stop. That means building the card network retry limits into your logic and mapping each decline code to its own retry rule. The rules and fees keep changing, so it's ongoing work.

The Build-vs-Buy Dunning Rubric

Compare what you lose to failed payments against what a build and a tool each cost, in three questions you can answer in order. Run that way, the build-versus-buy debate becomes a cost comparison instead of a gut call.

The build side costs real engineering time, and the buy side costs real subscription fees. The three questions put a dollar figure on each, so you can see which one is cheaper for your business.

Question 1: How much revenue are you losing to failed payments?

Multiply your monthly recurring revenue by your involuntary churn rate to get the dollars at risk each month. That figure is the most any dunning system, built or bought, can recover for you. It sets the size of the prize before you spend a dollar chasing it.

The rate is the number teams skip. Your involuntary churn depends on your billing mix and how old your stored cards are.

Use the churn rate calculator to size the revenue at risk before you answer the next two questions.

Question 2: What will your build actually cost?

A compliant dunning build runs 40-80 engineering hours up front, plus ongoing maintenance each quarter to track card network rule changes. The up-front hours are the part teams estimate.

The quarterly upkeep is the part they forget, and it's where the build ends up costing more than it looked.

Put the two sides in the same units and compare:

The build's up-front hours are a one-time charge, but the maintenance recurs every year, on top of the launch cost. Price your own engineering hour into the build column before you treat "we'll just build it" as free.

Question 3: Does your native platform already cover the gap?

Check what your billing platform's built-in recovery does before you build or buy anything on top of it. Stripe, Chargebee, and Recurly all retry failed cards on their own, and below a certain volume that native retry plus the default email sequence covers most of your gap.

Native recovery stops at the controls that lift the rate further, the ones a tool adds on top. If your platform's built-in dunning already reaches most of your at-risk revenue, you don't need a tool yet.

When your audit shows a wide gap between what's recoverable and what native dunning catches, that gap is what a tool is for. The next section puts a number on it.

When buying beats building (and what to look for in a tool)

Above $30k with 3% or more involuntary churn, a $200-500 tool pays for itself in month one, while an equivalent build takes a year to break even. Both recover the same revenue, so that timing gap is the whole reason buying pulls ahead here.

A purpose-built tool in the dunning management software category, from vendors like Churn Buster, Baremetrics Recover, and Stunning, adds the controls the native retry engines leave out.

The dunning process itself covers why each layer matters and where native tools stop.

Those controls are where the extra recovery comes from:

• A/B testing on subject line and copy, which raises the recovery rate.
• Behavioral triggers that retry on payday or a card replacement, when funds are likeliest.
• Churn-reason capture that records why the subscribers who never recovered chose to go.

Say a business runs $80k MRR, loses 4% to failed payments, and a $300 tool recovers 60% of the $3,200 at risk, netting $1,620 in month one. Plug in your own MRR and involuntary churn rate to see where you land.

The math flips at the low end. Below $30k MRR with under 2% involuntary churn, based on our analysis, a tool can cost more than it recovers. Staying native earns its place at that scale.

FAQ

Does Stripe have dunning management?

Yes, Stripe Billing includes Smart Retries, an automated email sequence, and a hosted card-update page, all built in and free to turn on. It retries and emails, but it can't test email copy or segment by decline reason, which is the gap a dedicated tool fills.

What is the best dunning software for SaaS?

The best tool is the one that scores highest on retry logic, email testing, churn-reason capture, network compliance, and ROI reporting for your billing setup. There's no single winner, because the right pick depends on your platform and your failed-payment volume.

Can I build dunning on top of Stripe Billing without breaking Smart Retries?

Yes, as long as your code never cancels the subscription while retries are still scheduled, since a cancellation tells Stripe to stop collection. Set the subscription end-state to "mark as unpaid" instead of "cancel" so the native retry engine keeps running underneath your logic.