Dodo Digest: Building Software Is the Easy Part. Maintaining Is the Real Job.

No dark-mode styles — this email renders the same in a dark client.

Hello everyone,

I was scrolling through The Paypers recently when I came across an interview titled 'What a well-designed payment recovery system needs to get right'. It got me thinking about something many founders underestimate: what actually happens after a payment fails.

TL;DR
- A recent interview on payment recovery got me thinking about how much goes into building reliable payment infrastructure. Retrying a failed payment is only one part of the equation.
- October has been a reminder of how exposed modern software can be, with incidents like the Railway breach and critical PHP vulnerabilities making headlines.
- For founders, especially those building alone, understanding security, infrastructure, recovery, and what happens when things break is just as important as writing code.
- At Dodo Payments, we've shipped Single Page Checkout, bringing the entire payment experience onto one page, alongside Dodo AI, custom retry schedules, improved account security, and several other updates.

When building a SaaS product, it's easy to focus on the visible parts: the checkout, the dashboard, and the features customers interact with. But building a product that genuinely solves a problem requires much more than shipping features quickly.

And with AI making development faster than ever, I think understanding what to build, why it matters, and how all the pieces work together is becoming increasingly important.

THE SIGNAL

One point from the interview stood out: payment recovery shouldn't be a system that blindly retries failed transactions. It needs to work alongside the core payment infrastructure.

Soft declines and temporary network errors may justify another attempt. Hard declines, such as lost or stolen cards, should stop immediately. Timing matters, too. Repeatedly retrying a payment that failed due to insufficient funds isn't likely to help.

There's also a cost to getting this wrong. Every failed attempt can carry network fees, and a few unnecessary retries can eat into the revenue you're trying to recover. If a payment shows signs of fraud or a potential dispute, continuing to retry it can create an even bigger problem.

The customer experience matters just as much. Temporary backend or network issues should ideally be handled silently. Customers should only be notified when they actually need to do something, such as update an expired card or complete an authentication step.

Good recovery is often invisible until customer intervention is needed.

We've believed in this approach at Dodo for a long time. Revenue recovery shouldn't be something you bolt onto a subscription product after failed payments become a problem. It needs to be part of the payment experience from the beginning.

That's why Dodo Payments has had automated retries built in, with safeguards against retrying hard declines. We've continued to improve this, and our latest release introduces custom retry schedules, giving businesses more control over when failed subscription payments are attempted again.

But payment recovery is just one part of a much bigger conversation about building reliable software.

WHY THIS MATTERS

Around the same time, I was seeing people on X call October Black October, with security incidents and vulnerabilities emerging one after another.

The Railway breach was particularly concerning. Hackers may have accessed encrypted environment variables belonging to some customers, potentially exposing credentials and API keys. Then came PHP2Shell, critical vulnerabilities that could allow remote code execution in PHP, which powers roughly 70% of websites. PingCAP, the company behind TiDB Cloud, also disclosed unauthorized access to some of its internal systems.

What concerns me isn't just the incidents themselves. It's how much of a modern product depends on infrastructure, libraries, and services that founders don't directly control.

I think solo founders and small engineering teams need to pay particular attention to this.

When you're building alone, it's easy to focus on writing code, connecting services, deploying, and moving on to the next feature. But what happens when an API key is exposed? When a third-party service goes down? Or when something breaks at 2 AM and customers are depending on your product?

These aren't edge cases. They're part of running software in production.

And with AI making it easier than ever to generate code and ship products, I think we're reaching a point where writing code is becoming the easier part of being an engineer.

Knowing what to build, why anyone should care, making sound architectural decisions, securing your systems, and knowing what to do when everything breaks? That's the actual job.

As software becomes easier to build, the responsibility of maintaining it only grows. More dependencies, integrations, and AI-generated code also mean more things that can go wrong.

You don't need to master every part of your infrastructure overnight. But you do need to understand what you're relying on, where the risks are, and how you'll respond when something fails.

Building fast matters. Building something that can withstand the unexpected matters just as much.

WHAT WE SHIPPED

This week, we've released Dodo Payments v1.120.40, with updates across checkout, AI, developer infrastructure, subscription management, and account security: https://docs.dodopayments.com/changelog/v1.120.40

The biggest update I'd like to highlight is Single Page Checkout: https://docs.dodopayments.com/features/single-page-checkout

We've made it possible to run the entire checkout experience on a single page. Customers can enter their contact details, choose a payment method, and complete their payment without navigating between multiple steps or leaving the page.

It's a small change in how checkout is presented, but the underlying goal is important: reduce friction between a customer deciding to buy and actually completing the payment.

You can enable it by setting feature_flags.single_page to true on a checkout session.

We've also added two payment method layouts. You can use an accordion to display payment methods in separate rows, or tabs to give each method its own tab, with wallet buttons displayed above them.

Apple Pay also validates the total amount and currency against what the customer originally saw, helping maintain consistency throughout the payment experience.

Alongside Single Page Checkout, here's what else we've shipped:
- Dodo AI in the Dashboard: Ask questions about your business, summarize sales, and carry out tasks such as issuing refunds or creating usage meters. Dodo AI asks for approval before making changes.
- Connected Apps for MCP and the CLI: AI assistants and the Dodo CLI can now authenticate through OAuth instead of relying on stored API keys.
- Custom Team Roles: Create roles with granular None, Read, or Write permissions for individual resources.
- API Key Access and IP Allowlists: Set permissions for each API key and restrict requests to approved IP addresses or CIDR ranges.
- Workload Identity: Let CI/CD pipelines and cloud workloads authenticate using short-lived tokens instead of long-lived API keys.
- Custom Payment Retry Schedules: Configure up to eight retries over a 30-day period, with individual waiting periods between attempts.
- Cancellation Retention Offers: Offer customers a discount when they try to cancel a subscription, giving them another reason to stay.
- Rebuilt Customer Portal: A redesigned subscription experience, with options for customers to retry failed payments and update their payment methods.
- Account Security: View active sessions and sign out of individual devices or all other sessions.

We also shipped improvements to refunds in the original payment currency, payment-level reporting, checkout forms, analytics, payouts, and subscription management. Checkout, the Customer Portal, and the dashboard are now available in Serbian and Croatian, and Checkout SDK 2.1 brings further improvements for developers.

It's a fairly substantial release, but the common thread is making it easier for businesses to collect payments, manage their customers, and build more reliably on top of Dodo.

ONE LAST THOUGHT

One thing I've been thinking about lately is that getting your product to work is only the beginning.

The real test is what happens when something doesn't work. When a payment fails, when a dependency gets compromised, when an integration goes down, or when a customer needs help and your system doesn't have an answer.

As founders, we need to spend more time thinking about those situations before they happen.

Ship quickly, experiment often, and use every tool available to you. But don't let the speed of building make you overlook the responsibility of running what you've built.

The best products aren't just the ones that work when everything goes right. They're the ones that know what to do when things go wrong.

Also, join our loving Discord community: https://discord.gg/dodo-payments-1305511580854779984

Best,
Rishabh Goel
Co-Founder, Dodo Payments

If you'd rather not receive emails like this, unsubscribe here: https://unsubscribe.dodopayments.com/api/unsubscribe/v1.Yi1kb2RvLXBheW1lbnRzLXptNGp2eUBtYWlsLm5ld3NsZXR0ZXJzZWFyY2hlbmdpbmUuY29t.OP6EJZSYmLOJP84ZqMrcUNMt9tPeG9RJv18-z61noZI

Accession

nse/dodo-payments/2026-11-12/6784

From

Rishabh Goel · rishabh@dodopayments.com

Sent

12 November 2026 · 14:00 UTC