The paper you’ve been asked to write has two columns. The decision in front of you has three options, and the missing one is the only one that gets cheaper while you think about it.

Waiting is a real strategy with a real cost. Because nobody ever computes that cost, waiting never wins the comparison, including in the cases where it should have.

Why the third column goes missing

Partly it’s format. Build versus buy is a template that exists in every organization, and templates are gravity.

Partly it’s incentive. Nobody’s year-end review says they successfully declined to purchase something. A recommendation to wait reads as an absence of work, even when producing it took more analysis than the alternative.

And partly it’s that waiting genuinely does cost something, and the people arguing for action are right about that. The mistake isn’t preferring action. It’s never putting a number on the alternative, so the comparison happens between one costed option and one uncosted one.

What happens when the column is missing

Composite, merged from a few document-heavy operations: a logistics operator, customs paperwork, an extraction and classification problem across roughly forty document types.

They evaluated in the spring and signed in month three. Reasonable process, decent product, no scandal. Illustrative numbers: about 180,000 in year one, three months of integration work from a team of four, and a two-year term.

Fourteen months later, the same capability shipped inside a platform they already licensed, at no incremental cost. Not as good, initially. Good enough for about seventy percent of the document types, which happened to be ninety percent of the volume.

Now, the honest read on that is not “they should have waited.” They got fourteen months of benefit they’d otherwise have missed, and their team learned things that made the second wave much faster. The failure was narrower: at no point did anyone write down what waiting six months would have cost, or what it might have saved. The decision to move now was never actually made. It was assumed, and then the analysis was built on top of the assumption.

The reverse case is just as common and gets less attention. Organizations that waited three years for the category to settle, and arrived with no internal skill, no data in usable shape, and no idea which of their processes were candidates. They saved license fees and lost the ability to move. That’s a worse outcome and a harder one to see, because the cost never appears on an invoice.

Costing the wait

Three components. All computable, none precise, and rough numbers beat no numbers.

The cost of the problem continuing. You have this already, from Lesson 2. If the problem costs a measured amount per month, then six months of waiting costs six of those. This is the number people expect and it’s the least interesting of the three.

The option value of what arrives meanwhile. In a category moving this fast, capability per unit of price has been falling steadily. If a reasonable expectation is that the equivalent function costs materially less in a year, waiting has a positive expected value that decays as the category matures. This is genuinely hard to estimate and you should say so in the paper rather than pretending to precision. A range and a stated assumption is honest. A point estimate is not.

The cost of not learning. The one that’s consistently underweighted. Every month you don’t run anything, your organization doesn’t discover that its data is in worse shape than the architecture diagram suggests, that the process has four undocumented exceptions, that the operations team has a workaround nobody told you about. You’ll pay that discovery cost eventually. Paying it later means paying it under more pressure.

The three columns, honestly

	Buy	Build	Wait
What it actually costs	License, integration, change management, and the run cost nobody forecasts	Salaries for four years, not the six-month project	The problem continuing, plus lost learning
What it buys	Speed, and someone to call	Fit, and control of your own roadmap	Optionality, and a cheaper entry later
Where it goes wrong	The thing you bought becomes the thing you can’t leave	Year two, when the people who built it move on	The wait becomes permanent because nobody set a trigger
When it’s right	The problem is common and your version isn’t special	The capability is the product, or the data can’t leave	The category is moving faster than your problem is

On building: the question is almost never can we build this. Teams can usually build a demo in a fortnight, which is precisely the trap. The question is whether you can run it for four years, through two staff turnovers and a model deprecation you didn’t schedule. Build costs are back-loaded and build business cases are front-loaded, which is why they so often look attractive and so often disappoint.

A wait that is actually a decision

An unbounded wait is not a strategy, it’s a failure to decide wearing a strategy’s clothes. What makes it real is two things written down.

A trigger. Either a date, or a named condition. We revisit in March. Or, we move when our current provider ships this in general availability, or when the backlog passes eleven thousand items, whichever comes first.

Work that happens during the wait. This is what separates the two kinds of waiting. If the six months are spent getting the data into shape, running a small internal experiment on the ugliest document type, and writing the security requirements you’ll need anyway, then you arrive at the decision point far better positioned. If the six months are spent doing nothing, you arrive in exactly the same place, six months poorer.

The second kind is the one that gives waiting its bad name, and it deserves the bad name.

One thing to do differently

Put wait in the paper as a full column, with a number, a trigger, and a list of what gets done during it.

You’ll probably still recommend buying. Most of the time that’s right. But the recommendation will have been made rather than assumed, and when someone asks you in eighteen months why you moved when you did, you’ll have an answer that isn’t “it was on the roadmap.”