xkcd 1205, Toilmeter, and the real ROI of automation

Everyone who automates work eventually runs into xkcd 1205: save a little time per run, repeat often enough, and eventually the script pays for itself.

The comic is a great first approximation. Toilmeter pushes it one step closer to real life by adding four practical modifiers: error rate, frustration, maintenance, and skill investment.

What Toilmeter actually does

Toilmeter is an interactive break-even grid:

• X-axis: time shaved per run (1s to 30m).
• Y-axis: task frequency (yearly to 50x/day).
• Each cell: total automation budget over a chosen horizon (1-20 years).
• Display mode: time or money (with an hourly rate input).

You can click any cell to pin it and get a breakdown plus a verdict — and the verdict flexes on who you are. With skill investment at zero, the ladder reads in the economic register most teams default to: Don't bother → Worth a script → Build the tool → Hire someone to build the tool. Dial skill investment up and the same numbers get a different voice: You: take the rep anyway → You: write the script — the practice is the payoff → You: build it yourself — the rep is the payoff. Same cell, same budget, different decision depending on whether the question is "is this worth the team's money" or "is this worth my Saturday."

The extension to xkcd 1205

The baseline comic logic is "saved time per run x number of runs." Toilmeter keeps that and layers in modifiers that teams feel immediately in practice:

• Errors avoided: if the manual process is error-prone, automation recovers rework time.
• Frustration multiplier: annoying tasks get a higher multiplier because interruption has cognitive cost.
• Maintenance cost: ongoing upkeep subtracts from the budget.
• Skill investment: a flat credit for the rep — the future-self value of having wired this kind of thing up once.

In tool form, the core shape is:

budget = ((time_saved + error_rate * error_cost) * runs * frustration_mult) + skill_bonus - maintenance

That gives you a realistic "how much effort is worth spending to automate this" estimate instead of a flat yes/no.

Why skill investment is a first-class modifier

The other three modifiers all price the task. Skill investment is the only one that prices you.

Every small automation is a rep. Wiring up a five-line shell script teaches you the same primitives you will reach for when the thirty-line one shows up next quarter: argument parsing, error handling, idempotency, "where do I put the cron." The first time you do it, it is slow and the budget on paper looks like a wash. The tenth time, you write it on autopilot — and the budget on paper stops mattering, because you have moved the floor of what counts as "worth automating" down for every future task.

The dual of this is the opportunity cost of not automating something small. You did not just lose time_saved × runs. You also skipped a cheap rep on a low-stakes target. When the high-stakes automation lands — the migration, the incident response, the integration that has to ship Friday — you are reaching for the same primitives cold, under pressure, with a deadline. The version of you that wrote ten throwaway scripts ships it. The version that decided each one was "below the line" stalls.

That is why skill investment is modeled as a flat one-time bonus, decoupled from frequency and time-shaved. The rep value belongs to the engineer, not the task. A one-second-per-run, once-a-year cell is normally a hard "don't bother" — until you mark it as New primitive and the bonus lights it up. The bonus ladder runs from Known cold (zero, you've done this a hundred times) up through Real practice, New primitive, Skill unlock, and Career rep (200 hours of future-self credit, on the order of a real skill compounding for years).

The verdict is perspective-dependent

The default copy assumes you are reading the budget from the outside: a tech lead deciding whether a task earns headcount, a manager weighing engineering hours against other work. That is the "build the tool" / "hire someone to build the tool" register — the language of allocating someone else's time.

Skill investment quietly switches the voice. Above Real practice, the verdict starts addressing you directly, because at that point the rep is the dominant variable and "hire someone" is no longer the right call — delegating the work also delegates the practice. "Hire someone to build the tool" becomes "Hire help, but stay close — own the parts that grow you." "Don't bother" becomes "You: take the rep anyway."

Both readings are valid for the same number. The grid says what the economics support; the role you are reading from picks which sentence applies. A senior engineer evaluating a tiny automation for the team will see one verdict; the same engineer evaluating it for themselves, looking to internalize a new primitive, will see a different one. The tool does not assume — it surfaces both, and lets the skill knob tell it which voice you are in.

Why this is useful in planning

The practical value is not that Toilmeter predicts the future perfectly. It is that it forces the right conversation before somebody burns a weekend on a script nobody maintains — or, just as importantly, before somebody talks themselves out of a fifteen-minute exercise that would have paid for itself ten automations from now.

If a task is frequent, error-prone, and infuriating, the budget usually supports a proper implementation. If it is infrequent and clean, the budget tells you to leave it alone or make a tiny tweak — unless it is a clean rep on a skill you do not yet have, in which case dial the skill knob and let the tool say it out loud.

That is the spirit of xkcd 1205, with knobs that match how engineering teams actually work, including the one that says: every small automation is also an investment in the engineer who will need it bigger, later.

Try it at osbytes.io/tools/toilmeter.