Should I Automate This? First Ask Whether It Should Exist
Before you automate something, ask what happens if nobody does it at all. If the answer is nothing, delete it instead.
Our own build gate skipped that question at first. Its first verdict was DON’T, for a small job that would remind the team about upcoming vacations. The arithmetic said it would lose about $6,200 a year. The verdict was right. The reasoning skipped a question, and I patched the gate the same night.
Building is too cheap now
With Claude Code doing most of the typing, building an internal tool feels nearly free. That feeling is the problem.
When I sat down to measure it in September, we were making roughly four internal build decisions a week. We had written 31 build plans since the start of July. One family of plans, for a single demo report, grew to seven plans in eleven days. And we had recorded the reasoning behind none of those decisions.
Two days earlier, an audit of our scheduled cloud jobs had turned up something worse. We had 20 jobs documented, with schedules, README sections and rows in our operating-rhythm doc describing them as running automation. Cloud Scheduler only runs a job when someone has created a schedule that sends work to it, and the audit found 11 live schedules. Eight of the documented jobs had never received a single request. About 2,500 lines of code, written, documented and scheduled on paper, doing nothing. The biggest was a 792-line meeting transcript sync, documented to run at 6 p.m. every day, that never ran once. Nobody noticed because each one looked finished.
AI-assisted building has a specific failure mode, and this was it: writing code got cheap, and owning it stayed exactly as expensive as before.
The gate
I built a skill called worth-it. When someone in a session proposes building a command, a job, a dashboard or a new version of something, it asks a fixed set of questions and records a verdict in a ledger. It’s advisory. Overriding it costs one line. The verdict gets recorded either way, with a review date, so the ledger can grade itself later.
The piece that does the most work is the rate card. It starts from the same math as xkcd’s Is It Worth the Time? chart, which tells you how long you can spend automating a task before you lose time over five years. The chart treats every hour as equal, and in a small company they aren’t. Build cost is priced at the builder’s hourly rate. Value is priced at the rate of whoever gets the time back. A founder hour costs the company a lot more than a staff hour, because the alternative use of a founder hour is a deal or a hire.
That asymmetry makes a whole category of build visible. When a founder spends an evening building something that saves an operations person twenty minutes a week, the time saved is real, and the math still comes out under water, because expensive hours went in and cheaper hours came back. The verdict for that case is DELEGATE: worth doing, wrong builder.
There are five verdicts in total (BUILD, DELEGATE, SHRINK, DEFER, DON’T), and one rule I’m fond of: guessed inputs can’t buy a big build. Above a certain build cost, if the frequency or time-saved numbers are guesses, the best verdict available is SHRINK. Go measure first, or ship something small and score it again.
The first verdict, and the question it skipped
The vacation reminder job was simple. Read the time-off table in Notion, post upcoming absences to Slack. About ten hours of appetite (a term from Basecamp’s Shape Up: decide what a thing is worth before asking how long it takes).
The gate priced it out: founder hours to build, a cloud job to maintain every month, a modest number of hours saved. Net about negative $6,200 a year. DON’T. It suggested a cheaper path: a native Notion automation that someone on the ops side could set up in about half an hour.
Good answer. But reading the ledger row back that night, I noticed what the gate never asked. It had evaluated whether to build the automation. It never asked whether vacation coordination needed a system at all.
Eliminate, automate, delegate: the step our gate skipped
Tim Ferriss has an ordering rule in The 4-Hour Workweek that I like a lot: never automate something that can be eliminated, and never delegate something that can be automated or streamlined. My gate had a DELEGATE verdict and no elimination step, so it skipped the first half of the rule entirely.
The patch added a question zero that runs before any arithmetic:
- What happens if this simply isn’t done? Who actually complains, and when?
- Is it productive procrastination, work that feels busy and moves nothing?
- Did it grow because of the time we gave it? (That’s Parkinson’s Law, from a 1955 Economist essay about the British civil service.)
If the work can be eliminated, the gate stops there. No payback math is owed to something that shouldn’t be happening. The commit message summed up the vacation case as “right answer, wrong door.”
Show the data
| Step | What it asks |
|---|---|
| Before any math | Is it cheap and reversible? Under the cost floor, skip the gate entirely |
| Question zero | Should this work exist? Who complains if it isn’t done? If it can be eliminated, DON’T, and stop |
| Rate card | Cost at the builder’s rate, value at the rate of whoever gets the time back |
| Return channel | Hours back, revenue enabled, or something sellable. Naming none is a DON’T |
| Appetite and maintenance | Net per year and payback in weeks. Net at or below zero, stop |
| Kill criteria | A date to judge it by. No kill criteria, no BUILD |
| Verdict | BUILD, DELEGATE, SHRINK, DEFER or DON’T. Guessed inputs on a big build cap at SHRINK |
| Person | Override in one line or accept. Either way, a ledger row with a review date |
The second verdict, which I partly ignored
The next day we scored a daily project health report: a job that would flag every active project missing an owner, assigned work or a milestone in the next three weeks. The evidence was real. A live query found 2 of 20 active projects with no usable owner, and 15 of 18 with no milestone inside three weeks. Nobody knew any of that without writing a script.
Verdict: DELEGATE. About $1,400 to build at an engineer’s rate, with kill criteria attached (if by early December fewer than three flags a month get cleared within a week, delete it). It also offered a smaller version: a Notion view plus a native automation, a couple of hours of admin work.
What shipped the next day was smaller than the plan in a different way. A weekly digest instead of a daily one, no model call, just arithmetic over a filter. The commit explains the weekly cadence better than I can: “a board that is 85% red on Monday is wallpaper by Wednesday.” So the checks that would have lit up most projects ship as dated countdowns instead of day-one flags.
And I built it myself, which is precisely what DELEGATE told me not to do. The ledger row still says DELEGATE with no override recorded. I’m telling you because the gate is only as honest as the people logging against it, and in its first week I was already the weak link.
The plan that was too well written
The clearest case so far was an internal browser for our standard operating procedures. The plan was genuinely good, nine carefully written decisions that had survived a stress-test session. It failed the gate on three independent grounds.
Version one rendered titles and owners, not the documents, so it saved nobody any reading time. It had no kill criteria, on purpose (“the site stays up regardless of traffic”). And the plan’s own risk section said the quiet part out loud: “Nothing in this plan makes an owner open the browser.”
The arithmetic compared about 36 hours of founder time, plus ongoing maintenance, against roughly 4 hours of someone adding properties and a filtered view in Notion. The plan already contained that smaller version as its first two steps. We had been about to build a website around a database view. What made our SOPs useful was how they were written and giving each one a single home, and neither of those needed a website.
The gate scored itself
I ran the skill on itself before building it. First estimate: 11.5 founder hours. With guessed inputs above the threshold, that capped at SHRINK.
Then someone pushed back that I was pricing a markdown file like a software project. The actual core (the skill file, two references, the ledger, a weekly panel) took about thirty minutes. That’s under the floor where the gate fires at all, which is the correct result for something cheap and reversible. The lesson generalizes: the first estimate is usually a project-shaped guess. Before scoring anything, ask what the smallest version that delivers the value actually is.
What I don’t know yet
The ledger has two rows. Both have review dates in December and no outcomes yet. The usage tracking that would tell us whether builds get used is still empty, which is its own story in We Built Three Feedback Loops. None Collected Anything. So I can’t yet tell you the gate pays for itself. I can tell you it killed one well-written plan and pointed two others at a Notion view. Since then we’ve also deleted 52 skills and commands, which is question zero asked after the fact.
Question zero is the part I’d keep if I threw everything else away. It’s also where I’d start with any team’s automation wishlist: who reads this report today, and what happens the week it stops arriving. Sometimes the honest answer is that nobody would notice.
The same question retired our own AI bookkeeper once a product we already paid for did the job (that story).
If you have a list, the setup planner asks six questions and sorts it without asking for an email. If you want a company brain that starts from that question instead of from a feature list, let’s talk.
