Before Automating Something, Ask Whether It Should Exist

The first verdict our build gate ever gave 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, went through seven versions 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 job endpoints documented, with schedules, README sections and rows in our operating-rhythm doc describing them as running automation. Eight of them had never received a single request. About 2,500 lines of code, written, documented and scheduled on paper, doing nothing. 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

So 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. 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.

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.

Tim Ferriss has an ordering rule 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?

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.”

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 decisions, stress-tested, carefully written. 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.

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.

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.

If you want a company brain that starts from that question instead of from a feature list, let’s talk.