The Fourth R — What Every Indie Dev Misses About Resilience
The Fourth R — What Every Indie Dev Misses About Resilience
Every indie developer knows about vulnerability scanners. Dependabot, npm audit, Semgrep — they are the first things you set up after git init. They block attacks. They are good at that.
But they only cover one of the four things you actually need.
Last week I read Sommerville's resilience engineering chapter (Software Engineering, 10th ed., Chapter 14) and realised something: the security tooling we all use stops at the first R — Resistance. Nobody tells indie devs what happens after the attack gets through. What do you do when a credential leaks at 2 AM? When the database goes silent? When you need to restore from a backup you have not touched in six months?
I shipped a Claude Code skill from it: /resilience-audit. It reads your repo and writes a cyber-resilience plan structured around the full 4R model.
The 4Rs in 30 seconds#
| R | What it means | What you probably have |
|---|---|---|
| Recognition | Detecting early signs of failure (logging, alerts, uptime monitors) | Probably nothing |
| Resistance | Stopping problems from becoming failures (auth, rate limits, isolation) | This is what scanners cover |
| Recovery | Getting critical service back fast (backups, failover, degraded mode) | Unverified, never rehearsed |
| Reinstatement | Returning to full normal ops (restore procedures, data validation, post-incident review) | Partial at best |
What the skill found when I ran it on my own SaaS#
I dogfooded it on a real indie project. The results were humbling:
- Resistance was solid — password hashing, rate limiting, secrets guarded at boot. Scanners had this half-covered.
- Recognition was nearly absent. No uptime monitor. No spend alerts. No failed-login alerting — despite the data being there to wire it up.
- Recovery was unverified. Database restore relied on the managed provider's default retention. I had never confirmed it worked. Never rehearsed it.
- Reinstatement was partial. Architecture decision records existed (so post-incident review had a home), but complete restore validation? No.
The top action the skill surfaced: "Rehearse a restore once. Until then you have hope, not Recovery."
How it works#
The skill reads your project (directory structure, config files, CI pipeline, dependency manifests) and writes a RESILIENCE.md plan at the repo root. It includes:
- An asset/threat matrix mapping what matters to what could go wrong
- A full 4R plan per critical asset
- Prioritised actions ranked by impact
- Incident runbooks — actual steps, not theory
If you have got the gh CLI authenticated and the repo is on GitHub, each prioritised action becomes a GitHub issue. Re-running the skill regenerates the plan but preserves anything you wrote between custom markers, so you can track progress without losing hand-written notes.
What it is not#
- Not a certification — resilience is a judgment, not a score. The output is a plan plus open questions. No pass/fail.
- Not a vulnerability scanner — keep using Dependabot and Semgrep. They handle Resistance. This fills in the other three Rs.
- Not done when generated — a runbook you have never rehearsed is not Recovery capability. The plan is the beginning, not the end.
Try it#
git clone git@github.com:adisagar2003/Software-Resilience-Skills.git
cp -r Software-Resilience-Skills/skills/resilience-audit ~/.claude/skills/
# cd into any project
/resilience-audit
It takes five minutes to set up. The first run might show you things you would rather not know. That is the point.
Built from Sommerville, I. (2016). Software Engineering (10th ed.). Pearson. Chapter 14 — "Resilience Engineering."