Ask Your Dev Team about their disaster recovery plan

Back in issue 9, we talked about risks: aging technology, infrastructure gaps, and runaway cloud costs. Disaster recovery is the plan for when those risks become reality.

The time to learn your developer has no recovery plan is not the moment your database disappears.

What disaster recovery actually covers

Disaster recovery isn’t one thing. It’s a set of practices that work together:

• Backups: Copies of your data stored separately from the primary system. These need to be automated, encrypted, and tested regularly. A backup you’ve never restored from is a backup you can’t trust.
• Failover: The ability to switch to a secondary system when the primary one fails. This can mean a second server in a different region, a redundant database, or a content delivery network that keeps serving users while the main system recovers.
• Data recovery: The process of restoring data from backups after a loss. How long does it take? How much data do you lose? These are measured in two metrics your developer should know: RTO (Recovery Time Objective, how fast you’re back online) and RPO (Recovery Point Objective, how much data you can afford to lose).
• Incident response: The human side. Who gets notified? Who makes decisions? What’s the communication plan for your users?

Recovery should be built in, not improvised

The best developers don’t treat disaster recovery as an afterthought. It’s built into the architecture from the start:

• Managed services with built-in redundancy (managed databases, cloud storage with automatic replication)
• Managed backups with verified restore processes
• Load balancing that distributes traffic across multiple servers, so one failure doesn’t take everything down
• Rollback automation that can revert a bad deployment in minutes, not hours

These aren’t nice-to-haves. They’re the difference between an incident that lasts five minutes and one that lasts five hours.

What to ask

1. “What’s your backup strategy, and when was the last time you tested a restore?” If they can’t answer the second part, the first part doesn’t matter.
2. “What happens if our primary server goes down right now?” You want to hear about failover, not about filing a support ticket and waiting.
3. “Do you have a documented incident response playbook?” A written, rehearsed plan beats a smart person figuring it out under pressure every time.
4. “What are our RTO and RPO?” If your developer doesn’t know these numbers, they haven’t thought about recovery in concrete terms.

Every client is different

A pre-revenue startup with 50 users doesn’t need the same disaster recovery plan as a fintech company processing millions in transactions. The level of investment should match the cost of downtime and data loss.

But at a minimum, every client should have:

• Proof that failure mitigation exists (backups, redundancy, monitoring)
• A documented playbook for how recovery works when something goes wrong
• A clear understanding of who is responsible for what during an incident

We’ll go deeper on monitoring in a future issue. For now, make sure your developer has a plan before you need one.

---

Expect better. Build better.