Why “Build Nothing Yet” Is Sometimes the Right Answer to an Automation Pitch

When “build nothing yet” is the right call

A handful of situations make the honest answer wait, and they are worth naming rather than discovering after the invoice.

• The process is not written down. If you cannot describe the steps in an agreed sequence, there is nothing stable to automate — you would be encoding a guess, not a process.
• The real bottleneck is a person or a policy, not software. A workflow can be wired perfectly and still fail if the underlying handoff between two people was never fixed — automation just makes the wrong handoff happen faster.
• Volume is too low to justify the cost. A process that happens six times a month rarely earns back a build price, however annoying it is to do by hand.
• You have not sized the problem, even roughly. Spending real money to fix a leak you have not sized is a guess wearing a budget.
• A previous attempt already failed for a reason nobody fixed. If the last automation project quietly stalled, the second attempt will stall the same way unless the actual cause got named and addressed first.

What “build nothing yet” is not

It is not “never automate.” The warning is not new: in Harvard Business Review in 1990, Michael Hammer wrote that companies “leave the existing processes intact and use computers simply to speed them up” (hbr.org). What this article argues for is sequencing: diagnose first, fix what turns out to be a people or process problem procedurally, and only then automate the parts that are proven, stable, and repeatable. Skipping the sequence is how businesses end up with expensive software quietly working around a process nobody ever fixed.

It is also not an excuse to avoid a decision indefinitely. “Build nothing yet” comes with a specific next step — measure, document, test by hand — not an open-ended pause. A yet with no plan behind it is just a no wearing a softer word.

And it is not a verdict on the person asking. An owner who gets told “build nothing yet” has usually correctly noticed a real problem — the pitch was wrong about the fix, not about whether something is worth fixing. The two are easy to conflate, and conflating them is how good instincts get talked out of acting at all.

Two illustrative scenes, one right answer each

Two hypothetical businesses. A property manager wants to automate late-rent reminders across forty units. The process is already stable — the same three-step reminder every manager already runs by hand — the volume is real, and a missed reminder costs little. This is exactly where “build it” is correct, and waiting would just keep costing the manual hours every month for no benefit.

A collision shop wants to automate its estimate-approval workflow, but three estimators currently approve jobs three different ways, and nobody has measured how many estimates actually stall versus how many just take a normal few days. Here, “build nothing yet” is correct — not because automation is wrong for shops, but because there is no single process yet to encode, and no confirmed number showing the delay is costing real jobs. The right first move is the same measuring and documenting described below, not a faster version of three different habits.

The one question that exposes a pitch

Ask whoever is pitching what it would take for them to conclude you should build nothing right now. If no answer exists, you are hearing a sales process, not a diagnosis. A longer version of this test, with the questions that expose each kind of firm in one call, is in the comparison of automation consultants and agencies.

What to do instead, this month

Four steps, in order, before anyone builds anything.

• Put a rough number on the problem. If it is inquiries that never get a follow-up, the free Leak Calculator turns four of your own numbers into an illustrative annual estimate in about a minute — an estimate, not a measurement. For any other process, keep a simple tally for two weeks: how often it happens, and how often it goes wrong.
• Write the process down by hand. Even a rough version exposes where the real ambiguity lives — often the same ambiguity a software build would have quietly encoded.
• Run it manually for two weeks. A short manual trial reveals the exceptions no planning session will surface, and it costs nothing but attention.
• Only then decide whether to build, and with whom.

None of these four steps require anyone else’s help, and none of them cost anything beyond your own time. If the process survives two weeks of honest manual running with the same steps holding up, you have earned the confidence to automate it — and a much clearer brief to hand whoever builds it.

If the diagnosis says build, we build. If it says wait, we say that.

The systems we build are only ever scoped after The Revenue Review, on purpose — the same discipline this article is arguing for, applied to how we run our own business. If two weeks in your own records shows a process is stable, high-volume, and worth automating, the Review says so and prices it. If it shows the opposite, the Review says that too, and the fee does not change either way. A 20-minute call is the cheaper way to find out which one your business is, before any commitment at all.