Interactive expected-value model · 8-year horizon · 10% discount
The choice isn't about the subscription fee — at any real revenue the fee is rounding error against the prize.
It comes down to two things: uncertainty (will an in-house build ever get prioritized, shipped, and measured?)
and time-to-market (every month of delay bleeds the lift). Set your revenue and watch the tree update.
$B / yr
Buy (Log2Spell)
+$84M
Build in-house
+$29M
Do nothing
$0
Risk- and time-adjusted, Buy ≈ 2.9× Build — and the gap is not about cost.
Why Buy wins — and it isn't the fee:
Uncertainty. Buy is ~0.80 to capture the lift, with a cancel option that caps the downside at a short trial.
An in-house build is ~0.30 once you account for getting it prioritized, staffed, shipped, and measured at all —
spell-correction perpetually loses the roadmap fight to indexing, latency, and ranking.
Time-to-market. Buy is live in weeks; a build averages ~7 months — and the lift bleeds the whole time.
On a $20M/yr lift, a 6-month delay alone is ~$10M gone, often more than the entire build cost.
Opportunity cost. The engineers a build would consume are already earmarked for other roadmap work —
often higher-value than spell-correction. Buying keeps them on it; building trades a $20M/yr lift for whatever they don't ship instead.
You don't replace your current spell checker — you cover its blind spot
The tell that you have this problem: your search only triggers spell-correction when a query returns
zero results. But most misspellings don't return zero — they return a different, worse set of results.
Those never trip the null-result check, so they silently convert at a lower rate. If that's your setup, the lift is sitting there uncaptured.
Keep your null-result fallback. Log2Spell sits in front of search and corrects proactively from your own logs, catching exactly
those misspellings that return poor (non-empty) results. Your existing checker stays as the long-tail safety net for true zero-result cases.
The union covers strictly more than either alone — additive, not rip-and-replace.
Verify the lift on your own log — before you commit
You don't have to take the model on faith. There's a cheap, ~afternoon test that measures the incremental value directly,
and it's the same reason the downside is capped: if the signal isn't there, you walk away having spent a trial.
Build an endpoint from your query log. Corrections come from your own traffic — no generic dictionary.
Pull a sample of 100 corrections Log2Spell produces.
Bucket each one by whether your current null-result path would already handle it — i.e., does the
original misspelled query return zero results today?
Already caught by the null path — your existing checker handles it. Redundant.
Not caught — the original returns non-empty but worse results today. Invisible to your fallback, converting below potential. These are the incremental wins.
Count the incremental bucket. If ~20% or more of the sample is incremental, that's a strong green light — on the ~10% of traffic that's misspelled, a 20% incremental correction rate is a large conversion pool you're leaving on the table.
already caught by null path (redundant)
~20% incremental → likely lift
Sample of 100 corrections. The green slice — corrections your null path can't see — is the signal. ~20%+ ⇒ adopt.