research/documentation-as-leverage
Documentation as Leverage: Runbooks and Decision Logs for Small Companies
Original Research • October 28, 2026 • 11 minute read
Executive Summary
Documentation, for a small company, is the written record that lets someone other than the founder keep the business running: runbooks for tasks, a decision log for reasons, and tests that prove what works.
Most small companies run on memory. The founder knows which account holds the domain, why the pricing page says what it says, what to do when the contact form stops sending email, and which customer must never be called before ten. This works well until the day the founder is sick, traveling, or simply too busy to answer, and then the company discovers how much of its operation was never written anywhere.
This paper argues that documentation is best understood as leverage, not overhead. A few well-chosen documents, namely runbooks for recurring tasks and failures, a decision log for the reasoning behind choices, and tests that double as proof of what works, let a business keep running without its founder in the room. They also make the founder faster on ordinary days. We describe what to write first and a minimal template in prose, with no special tooling required.
Write down only what you would be unable to reconstruct under stress, and keep it close enough to the work that it stays true.
What happens when the founder is unavailable?
Run a simple thought experiment. Suppose the person who built and runs your business is unreachable for two weeks, with no warning. What breaks first?
For many small companies the answer is mundane. A renewal date passes because only one person knew it. An email stops arriving and nobody knows where it is configured. A customer asks a question whose answer is a decision made years ago for reasons now forgotten. None of these is a disaster individually.
The usual response is to schedule a documentation project, which collapses under its own ambition. Someone opens a blank document titled “Everything,” writes for an afternoon, and never returns. The material goes stale, nobody trusts it, and the habit dies. A better approach is to write small, specific documents at the moment the knowledge is freshest, and to treat each as a repair to a particular weakness.
Deciding what deserves a document: frequency and consequence
Not everything is worth writing down. Two questions sort tasks quickly: how often does it happen, and how bad is it if it goes wrong?
| Low consequence | High consequence | |
|---|---|---|
| Frequent | Keep in your head, or a short checklist | Checklist or automated test, used every time |
| Rare | Skip, or a two-line note | Full runbook, written now, tested once |
The bottom-right cell is where documentation pays most. Rare, high-stakes tasks are the ones nobody remembers and everyone fears: renewing the domain, restoring a backup, recovering a lost login. The top-right cell is where automation pays most, because a frequent, high-stakes task done from memory will eventually be done wrong.
what the business depends on ---> one-page dependency list
|
v
what would hurt most if it broke ---> runbook for each
|
v
why things are the way they are ---> decision log
|
v
what must always work ---> smoke test or checklistRead it top to bottom as an order of work. Each layer rests on the one above it: you cannot write a good runbook for a system you have not listed.
What is a runbook, and which tasks need one?
A runbook is a step-by-step description of how to do one thing. The best candidates are tasks that are infrequent, important, and easy to get wrong: renewing a domain, restoring from a backup, deploying a change, onboarding a new client, handling a failed payment, rotating a password that several tools depend on.
Frequency is what makes them valuable. A task done daily lives in muscle memory. A task done twice a year is relearned every time, at a moment when you are probably already under pressure, and the relearning is where the mistakes happen.
A good runbook is shorter than people expect. It states what the task is for and when to do it. It lists what you need before starting, such as access to certain accounts, in a way that tells the reader where to look and never includes the secrets themselves. It gives the steps in order, each one a single action with its expected outcome, so the reader can tell whether they are on track. And it ends with how to confirm that the task worked and what to do if it did not.
Write it by doing the task once with the document open and recording what you actually do. Then ask someone else to follow it, or follow it yourself a few months later, and fix every place where it was unclear. Two passes make a runbook useful.
A runbook template
Copy this into a file named for the task. The expected result on each step is what lets a tired reader tell whether they are still on track.
TITLE: How to ______________
WHEN TO DO THIS: ______________ (trigger, or how often)
LAST TESTED: ________ BY: ________
YOU NEED
- Access to: ______________ (where the login is kept, who can grant it)
- ______________
STEPS
1. ______________. Expected: ______________
2. ______________. Expected: ______________
3. ______________. Expected: ______________
CHECK IT WORKED
- ______________
IF IT DID NOT WORK
- First, ______________. Then ask: ______________
- Roll back by: ______________What is a decision log?
Runbooks capture how. A decision log captures why, and the why is what disappears fastest.
Every business accumulates decisions that look arbitrary from outside: we use this tool and not that one, we do not offer that service, we always require a deposit before starting. At the time, each had reasons, and often good ones. A year later the reasons are gone, and someone, quite possibly you, is tempted to reverse the decision without knowing what it cost to arrive at it.
A decision log is a plain list of entries, newest first, each a few sentences long. An entry says what was decided, what the alternatives were, why this one won, and what would make you revisit it. The last part is the most useful. “We chose to host in one place for simplicity; revisit if monthly traffic outgrows what the plan allows” tells a future reader that the decision was conditional, and what the condition was.
Entries should be written on the day, while the argument is still in your head. If one takes more than five minutes, you are writing an essay, and essays are rarely finished.
This is the same instinct we describe in our case for boring web architecture, where every added component is supposed to earn its place in writing. A log is where that earning is recorded.
A decision log template
One entry takes five minutes. Newest entries go at the top of the file.
DATE: ________ DECIDED BY: ________
DECISION: We will ______________.
OPTIONS CONSIDERED: A) ________ B) ________ C) do nothing
WHY THIS ONE: ______________
WHAT WE GIVE UP: ______________
REVISIT IF: ______________The two fields people skip, “what we give up” and “revisit if,” are the ones future readers need most. A decision with no stated cost looks like it was free, and a decision with no revisit condition looks like it was permanent.
Tests as documentation that cannot lie
Prose goes stale. Someone changes the system and forgets to change the page that describes it. The only documentation that reliably stays true is documentation that fails when it is wrong.
For anything with software behind it, that means automated checks. A smoke test, a short script that loads the key pages, submits the contact form in a test mode, and confirms the expected result, is a precise statement of what must work. Read as documentation, it says: these are the things this business depends on. Run on a schedule or before each change, it says the moment one of them stops being true.
Smoke tests have a second benefit for a small team: they replace the unspoken checklist in the founder’s head. “Before I deploy I always click through the form and the checkout” becomes a thing a machine does and anyone can run. Choose a handful of journeys that would hurt most if broken, and test those. A small, trusted set beats a large one nobody maintains.
The same principle applies outside software. A written checklist that is used on every occasion, with real checkmarks, behaves like a test: if a step is wrong, someone notices because they are following it.
Writing for your future self
The most useful reader to imagine is yourself in six months, tired, interrupted, and slightly annoyed. That person has forgotten the context, does not remember which account was used, and does not want to be taught anything. They want to be told what to do.
This points to a few habits. Use plain words and the names of things as they appear on screen. Say where things are and not what they are called in your head. Put the most important instruction first. Include dates only where they matter, and when you must, explain how to find the current value instead of copying it, since copies go stale. Never put passwords or secrets in documentation; record where they are stored and who can grant access.
Keep documents small and findable: one folder, or one directory in the project repository, with sensible file names. If you cannot find the runbook in thirty seconds during a bad moment, it effectively does not exist.
How do you start documenting a small company?
Begin with the next three occasions on which something goes wrong or you repeat something you wish you had written down.
A sensible order looks like this:
- A one-page list of what the business depends on: domains, hosting, email, payment, the accounts behind them, who can access each, and where renewals are tracked.
- A runbook for the thing that would hurt most if it broke, probably the website going down or email stopping.
- A runbook for deploying or publishing changes.
- A decision log, started today with the three biggest choices you can remember, plus an entry whenever you make a new one.
- A short smoke test or checklist for the journeys that earn money.
The minimal template for any runbook fits in one sentence: a title that says what the task is, a line on when to do it, a list of what you need, numbered steps with expected results, a way to check it worked, and a note on what to do if it did not. For a decision, the template is: what we decided, what else we considered, why, and when to revisit.
A worked example (illustrative)
Consider a hypothetical six-person print shop whose founder handles the website, the domain and the order email. We run the framework on it.
The dependency list comes first. It has five lines: the domain and where it renews, the hosting for the website, the email provider, the payment processor, and the folder where customer artwork is stored. Each line gives who can log in and where the credentials are kept, not the credentials themselves. Writing it takes twenty minutes and already exposes a problem: only the founder has access to the domain account.
Then the frequency and consequence table sorts the tasks. Renewing the domain is rare and high-stakes, so it gets a full runbook. Publishing a price change is occasional and moderate, so it gets a short checklist. Answering routine questions is frequent and low-stakes, so it gets nothing.
The first decision-log entries come from memory: why the shop requires a deposit on custom jobs, and why artwork is stored in one shared folder with a naming rule. Each takes five minutes and ends with a revisit condition.
Finally, a smoke test. For a site like ours, pages are Astro static output on Cloudflare Pages, with a few Functions, a D1 database and R2 storage, and a full build of well over a hundred pages takes about ten seconds. Fast builds make a check before every publish cheap, so the test, which loads the key pages and submits the contact form in test mode, runs every time. Whatever stack the print shop uses, the principle holds: the check should be cheap enough that nobody skips it.
After a week of this, the founder can be unreachable for two weeks and the business degrades gracefully instead of stopping.
Conclusion
Documentation earns its keep by converting private knowledge into something a business can use without its owner present. It does not have to be large or beautiful. A dependency list, a few runbooks, a decision log, and a handful of tests cover the failures most likely to hurt a small company, and each takes minutes to create at the moment the knowledge is fresh. Start with the next problem you solve, write it down while you remember, and keep it where the work happens. The payoff arrives on a day you cannot predict, when someone else keeps the lights on and you are free to be somewhere else.
Related reading
- A Runbook for a One-Person Operation
- The Case for Boring Web Architecture
- Automating Accessibility Checks with axe and Playwright
Frequently asked questions
What is a runbook?
A runbook is a step-by-step description of how to do one task, such as renewing a domain, restoring a backup or deploying a change. It states when to do the task, what you need, the numbered steps with expected results, how to confirm success, and what to do if it failed. It never contains passwords.
What is a decision log?
A decision log is a plain list, newest first, recording what was decided, what alternatives were considered, why this one won, and what would make you revisit it. It preserves the reasoning, which fades faster than the procedure, so that future you does not reverse a good decision without knowing its cost.
What should a small business document first?
Start with a one-page list of what the business depends on: domains, hosting, email, payments, who can access each and where renewals are tracked. Then write a runbook for whatever would hurt most if it broke, a deployment runbook, a decision log, and a short checklist or smoke test for the journeys that earn money.
How do you keep documentation from going stale?
Keep it small, store it next to the work, and write it when the knowledge is fresh. Prefer documentation that fails when wrong, such as automated smoke tests and checklists people actually follow. Explain how to find current values instead of copying them, and fix the document whenever it misleads someone.
Should I put passwords in my documentation?
No. Record where credentials are stored and who can grant access, never the secrets themselves. A runbook should tell the reader which account or vault to open and who to ask, so the document is safe to share with a contractor or a new hire without exposing anything.
How long should a runbook be?
Shorter than most people expect, usually a page. It should contain one task, in plain words using the names of things as they appear on screen, with the most important instruction first. If it grows past a page, it probably describes several tasks and should be split.