A travel-search platform aggregating supplier prices - the business shape Expedia operates in - measures 40 million price updates a day and must choose between a managed search service and running the engine itself. A two-engineer two-week spike would settle it. Work out when buying that information is cheaper than deciding now.

The assumptions, stated

Four numbers decide this, and only one of them is usually argued about.

• Price of the spike. Two engineers for two weeks is 4 engineer-weeks, about 160 hours. At roughly $100 to \(150 per engineer-hour fully loaded in 2026 for a senior engineer in a high-cost market, that is **\)16k to $24k**. Call it $20k.
• Price of the delay. Two weeks of calendar time on a feature worth roughly \(200k a quarter is about **\)30k of deferred value, and this is the number teams forget. The spike's true price is about $50k**, not $20k.
• Cost of being wrong. If the choice is wrong, you discover it in production in 6 to 12 months and pay a migration: re-indexing a 40M-updates-a-day pipeline, dual-running both engines, re-tuning relevance, and re-training the operators. Two engineers for three months is 24 engineer-weeks, six times the spike, so roughly $120k to $180k plus another quarter of delay. Call it $150k.
• Probability of being wrong without the spike. Two plausible options and no first-hand evidence puts this near a coin flip. Roughly 0.4.

The arithmetic

Buy the information when its price is below the expected cost it avoids:

price of spike  <  P(wrong) × (cost of correcting later − cost of correcting now)
$50k            <  0.4 × ($150k − $0)  =  $60k        → buy the spike

Now change one input. If the team already runs that engine in production elsewhere, P(wrong) drops to about 0.1, so the expected avoided cost is $15k against a $50k price, and the correct move is to decide now and spend the two weeks shipping. The decision flips on the probability, not on the spike's cost.

Which assumption dominates the error

P(wrong) dominates, and it is the one nobody writes down. The second is reversibility, which is hidden inside "cost of correcting later". A choice behind an interface you control — a search abstraction with two implementations — has a correction cost closer to $40k, and at that level 0.4 × $40k = $16k does not justify a $50k spike. Spending on reversibility and spending on information are substitutes, and the cheaper one is usually reversibility.

The test that makes a spike real

Before it starts, write down the observation that would change your choice: "if the managed service cannot sustain 40M updates a day inside the ingest window at list price, we self-host". If no observation would change the choice, the spike is not an experiment, and you are buying comfort at $50k. That single line also fixes the other failure: a spike with no stop condition that runs five weeks because it became interesting. Timebox it, and treat an overrun as evidence that the real cost of self-operation is higher than the proposal assumed.

What the number rules in and out

It rules out the six-week evaluation, because 6 weeks costs roughly $150k all-in and equals the cost of being wrong — at that point you should simply pick one and keep the migration path. It rules in the two-day version: for many decisions the information worth buying is one reference conversation with a team running the thing at your volume, which costs an afternoon and moves P(wrong) more than a benchmark does.

Common weak answers

• "Always spike before a big decision." This treats information as free. At $50k a spike, an organisation making 20 decisions a quarter cannot afford the policy, and the spikes crowd out delivery.
• "We do not have time; just pick one." Right conclusion, wrong reasoning, and it fails exactly where it matters: the one-way door with a $150k correction cost. The arithmetic tells you which decisions deserve the two weeks, and it is a small minority of them.