<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>startup resilience on Kuldeep Pisda</title><link>https://kdpisda.in/tag/startup-resilience/</link><description>Recent content in startup resilience on Kuldeep Pisda</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sun, 30 Nov 2025 12:34:46 +0530</lastBuildDate><atom:link href="https://kdpisda.in/tag/startup-resilience/index.xml" rel="self" type="application/rss+xml"/><item><title>Disaster Recovery Planning Checklist: The Guide I Wish I Had Years Ago</title><link>https://kdpisda.in/disaster-recovery-planning-checklist-the-guide-i-wish-i-had-years-ago/</link><pubDate>Sun, 30 Nov 2025 12:34:46 +0530</pubDate><guid>https://kdpisda.in/disaster-recovery-planning-checklist-the-guide-i-wish-i-had-years-ago/</guid><description>&lt;p&gt;It&amp;rsquo;s 3 AM, and your phone lights up with a PagerDuty alert. The main database is just… gone. Not slow, not lagging. Unresponsive. As an engineering lead, my stomach used to drop just thinking about this. We were all moving at light speed, shipping features, chasing that elusive product market fit. Who has time to plan for a catastrophe that might never happen?&lt;/p&gt;
&lt;p&gt;I learned the hard way. A client of mine once had their entire Redis cluster—the one handling every critical user session—vaporize because of a misconfigured cloud script. The scramble to recover was a painful, frantic ballet of engineers trying to remember how everything was wired together. It revealed just how fragile our &amp;ldquo;it will probably be fine&amp;rdquo; assumptions were. That experience forced us to stop and ask the real question: what is our actual plan when things go sideways?&lt;/p&gt;</description></item></channel></rss>