I launched Disaster Lab: know what to do when something breaks

Today I launched Disaster Lab.

Disaster Lab is a free library of practical playbooks for digital disasters.

It helps with situations like:

• your phone is lost or stolen
• your personal email is hacked
• your GitHub organization is compromised
• production data is deleted
• your domain expires
• customers are charged twice
• a cloud region goes down
• a contractor disappears without a handover

The launch catalog contains 56 playbooks.

Six are for everyday life. The other 50 are for people running software businesses.

Every playbook has two sides: what to do when the problem is happening, and what to prepare before it happens.

Why I built it

Most disaster plans are written after the disaster.

That is too late.

When something important breaks, people do not need a long explanation of the topic. They need the next safe action.

They need to know what to do in the first 15 minutes, what evidence to keep, what not to destroy, who to contact, and how to tell if control is really restored.

The same problem exists before an incident.

Advice like “have backups”, “rotate credentials”, or “review access” sounds good. But it does not tell you what a working backup looks like, which credentials matter, where to revoke them, or how to prove a second person can recover the system.

I wanted something more concrete.

Disaster Lab turns each scenario into an ordered plan.

Two ways into the site

The homepage asks one question:

Is something broken right now, or do you want to stop it from happening?

If something is broken, the emergency directory takes you straight to the recovery steps.

If you are preparing, the prevention directory shows the safeguards for each scenario and starts with the quickest work.

This split sounds small, but it changed the whole site.

Someone dealing with a hacked account should not have to scroll through backup advice before finding the first urgent action.

Someone preparing on a quiet Friday should not have to read the site as if the building is on fire.

The underlying playbook is the same. The entry point and the order are different.

What is inside a playbook

Each playbook starts by explaining what the incident means and how to recognize it.

Recovery then follows the same broad order:

1. first 15 minutes
2. today
3. verify recovery
4. after recovery

The preparation side covers access, backups and evidence, contacts and ownership, and a small practice exercise.

The details change for every scenario.

A compromised GitHub organization needs audit logs, owner recovery, deployment containment, downstream secret rotation, and a clean comparison of repositories and workflows.

A stolen phone starts with email, the device lock, the SIM, and the two-factor codes that protect other accounts.

Generic advice would make both pages shorter. It would also make them much less useful.

The operator worksheet

Every business playbook includes an operator worksheet near the top.

The worksheet follows one simple flow:

Evidence → Decision → Action → Proof

It lists what to preserve before logs or state disappear. It then shows the decisions that change the response, the condition for each decision, and the action to take.

It finishes with proof that recovery worked, preventive controls, a tabletop drill, and the point where specialist help is needed.

I added this after building the first version of the catalog.

The early playbooks had the right headings, but a heading is not operational depth.

“Check the logs” is not enough.

Which logs? Which fields? What time range? What are we trying to prove?

The worksheet forces every business playbook to answer those questions.

Personal disasters need different writing

I originally built Disaster Lab for software businesses.

Then I realized the same format could help with the digital incidents people face outside work.

I added playbooks for a stolen phone, a hacked personal email, lost personal files, account lockout, social account takeover, and fraudulent charges.

These are not shortened business playbooks.

A person at home does not have an identity provider, a security team, an account manager, or an incident channel.

Sometimes the only real next step is to call the bank, suspend the SIM, or wait for an account recovery process.

The writing has to match that reality.

It also has to recognize the human obstacle. Panic can make someone erase a phone too early. Embarrassment can stop someone reporting fraud. A good playbook should remove those mistakes, not add more technical language.

Country-specific procedures

Some recovery steps have the same shape everywhere and completely different mechanics.

Reporting a stolen phone, replacing a SIM, disputing a fraudulent payment, and notifying a data authority all depend on where you live.

I did not want to create a separate version of every playbook for every country.

Instead, Disaster Lab has a small country procedure library.

The playbook asks what you need to do. The country layer supplies the local process, documents, deadlines, costs, regulator, official sources, and the easy-to-miss detail.

The same Italy police-report procedure can appear wherever a playbook needs a police report.

The same European Economic Area baseline can explain shared PSD2 or GDPR rules without pretending that the local mechanics are identical.

The launch version includes detailed procedures for Canada, France, Germany, Italy, the Netherlands, Spain, the United Kingdom, and the United States. It also covers the shared rules and data authorities across the rest of the EEA.

Your country choice is saved in the browser. Pick it once and the relevant procedure follows you across the site.

Platform-specific instructions

The same issue appears with operating systems.

The steps for locking an iPhone are not the steps for locking an Android phone. Recovering a laptop also changes between macOS, Windows, and Linux.

Disaster Lab uses platform tabs only when the mechanics are genuinely different.

Choose your platform once and the site remembers it.

General guidance stays outside the tabs. You only switch the part that really changes.

This keeps a Windows user from having to read through macOS commands to find the next action.

The checklists stay in your browser

The preparation checklists are interactive.

When you tick a safeguard, Disaster Lab saves that progress in localStorage.

There is no account and no database.

The preparation directory can read the same local progress and show which playbooks you started.

The percentage is calculated separately for personal and business playbooks. A business operator should not look unprepared because they did not complete a personal phone checklist, and the opposite is also true.

You can also print any playbook.

In a real incident, a browser tab should not be the only copy of the plan.

How I built it

Disaster Lab is data-driven.

Each playbook is a Markdown or MDX document with structured frontmatter.

The shared schema looks like this:

{
  title: String,
  slug: String,
  summary: String,
  category: 'access' | 'infrastructure' | 'people' | 'data' | 'money' | 'vendor',
  audience: 'personal' | 'business',
  severity: 'disruptive' | 'serious' | 'critical',
  timeToPrepare: String,
  lastReviewed: Date,
  incidentReports: [],
}

Astro loads the documents as a content collection. Zod checks the frontmatter during the build.

One dynamic route generates every playbook:

export async function getStaticPaths() {
  const playbooks = await getCollection('playbooks')

  return playbooks.map(playbook => ({
    params: { slug: playbook.data.slug },
    props: { playbook },
  }))
}

The page combines the document with shared components for the incident flow, operator worksheet, category illustration, real incident reports, checklist progress, local procedures, and platform tabs.

This gives every playbook the same basic interface without forcing the content into one generic template.

How the build checks depth

A content schema can prove that a title exists.

It cannot prove that the recovery advice is useful.

For the business playbooks, I added a second data layer with the operational details:

• evidence to preserve
• decisions and their criteria
• proof that recovery worked
• controls to prevent a repeat
• a tabletop drill
• escalation triggers

The build checks that every business playbook has this depth.

If one is missing, the build stops and lists the incomplete scenarios.

Each page also shows its last-reviewed date and links to official sources.

Where I found a useful firsthand postmortem or official incident report, I added it separately from the general guidance. At launch, 13 playbooks include 14 real incident reports.

This distinction matters.

Official documentation explains what a provider supports. A postmortem shows what happened when a real system failed.

Neither source is enough on its own, and neither makes the site permanently correct.

Guidance changes. Providers change their dashboards. Laws, deadlines, and recovery routes change.

Disaster Lab has to be maintained, not just generated.

An interesting thing about the first version

The first commit had four playbooks:

• GitHub organization compromised
• domain expired or lost
• website hacked
• contractor disappears

The next day the catalog had 50.

That was the breadth-first pass.

Then I stopped adding scenarios and went back through the entire catalog. I deepened the playbooks, added the operator worksheets, and made the build reject missing operational depth.

Before launch I added the personal track, real incident reports, platform-specific steps, and country procedures.

This is a good example of how I now build software.

First I prove the product shape with a small version. Then I use the factory to expand it. Then I make the constraints tighter and remove the weak parts.

This is another result of my software factory

Disaster Lab is another product from my software factory.

The factory is not one giant prompt that builds a website.

It is a repeatable system made of a written plan, repository rules, focused tasks, specialized agent roles, review gates, and automated checks.

AI coding agents did much of the production work.

They helped build the site, research incidents, expand the catalog, create the operator worksheets, add country procedures, and check different parts of the product.

My job was deciding what the product should be, defining the content standard, splitting the work, reviewing the results, and changing direction when the first version was too shallow.

The factory made it possible to go from four playbooks to a large, structured catalog quickly.

It also created the main risk.

AI can produce confident disaster advice at incredible speed.

Confident advice is dangerous when it tells someone to destroy evidence, erase a device, rotate the wrong credential, or trust a recovery that only looks complete.

This is why the useful part of the factory is not raw output.

It is the standard around the output: primary sources, explicit limits, last-reviewed dates, concrete verification, build checks, and human review.

The factory gives me leverage. It does not remove responsibility.

The development stack

Disaster Lab uses the AHA Stack:

• Astro generates the complete static site
• HTMX makes normal page navigation feel faster
• Alpine.js runs filters, checklists, platform tabs, and country selection

The rest is deliberately small:

• Markdown and MDX contain the playbooks
• TypeScript defines the shared operational and country data
• Zod validates the content collection
• plain CSS handles the design
• localStorage keeps progress and preferences in the browser

There is no database, account system, API, or server-rendered application.

The deployment stack

Disaster Lab is deployed to Cloudflare Pages.

The deployment command first runs:

npm run build

That runs astro check and builds the static site. Wrangler then uploads the generated dist directory to Cloudflare Pages.

If the content schema is invalid or a business playbook has no operational depth, the deploy stops.

There is no Astro adapter, serverless function, secret, or database migration.

The site is static HTML, CSS, and JavaScript.

This matters for a site people might open during an incident. There are fewer moving parts, nothing to sign in to, and almost nothing for me to operate.

What could Disaster Lab become?

The first job is not adding another 500 playbooks.

It is making the current 56 better.

I want to add more real incident reports, test the playbooks with operators, improve the local procedures, and keep provider-specific steps current.

The review date could become more useful too. Old guidance should not look as trustworthy as something checked last week.

I can also see the site becoming more personal.

You could answer a small set of questions about your company: where the domain lives, who controls GitHub, where backups go, how payments work, and which person owns each critical system.

Disaster Lab could then assemble a continuity plan for that specific business.

I do not want to build that yet.

The pre-made playbooks should prove that the format is useful first.

Another direction is team readiness.

A team version could add owners, due dates, shared progress, evidence, recurring reviews, and scheduled tabletop drills. It could show which systems depend on one person and which recovery paths have never been tested.

The free site would remain the public reference. The team product would help a company turn the reference into an operating process.

Possible business ideas

I am not interested in making money from Disaster Lab right now.

This is a fun experiment.

I wanted to see if my software factory could turn the idea into a useful product. I like that the site exists, and that is enough for now.

But no one knows what the future will bring.

Disaster Lab might stay a free little site. It might grow into a much bigger library. It might become a business one day.

Everything is possible, so I am keeping every option open.

I wrote two possible business ideas in the original plan.

The first was a one-time $49 disaster pack.

It could include printable playbooks, communication templates, an account and vendor inventory, emergency contact sheets, a credential rotation worksheet, tabletop exercises, and a recovery verification report.

The second was a $99/month team product.

That could add shared assessments, named owners, review reminders, progress tracking, private company details, and an audit trail of completed drills.

Those are ideas, not a roadmap.

There are other possible businesses around the same library:

• paid tabletop sessions for small teams
• a continuity audit for solo founders
• custom incident packs for one company or industry
• a maintained private handbook for agencies and their clients
• referrals to vetted security, legal, insurance, and recovery specialists

The interesting part is that the free playbooks can be the top of the product.

They help someone immediately. They also reveal where a generic plan stops being enough.

That boundary is where a paid product or service could begin.

If I ever decide to make it a business, I will let usage guide the decision.

The playbooks people print, the scenarios people request, and the preparation steps people start will tell me more than inventing a pricing page now.

Try it

Open Disaster Lab.

Choose Something is broken if you need help now, or Stop it happening if you have twenty quiet minutes to prepare.

The playbooks are free and do not require an account.

If you have handled one of these incidents, found an unsafe or unclear step, or want a playbook for a scenario I missed, let me know.

Related posts about news: