A bug a linter would've caught in 200 milliseconds instead took three weeks and a customer escalation to surface. Not because it was subtle. Because nothing below the customer was actually watching.

That's the shape of almost every expensive mistake: not a hard problem, a missed rung. So here's the whole ladder, laid out once, properly, so you can see exactly which rung was empty next time it happens.

The ladder, rung by rung

Syntax errors get caught by your editor or compiler. Cost is near-zero — it shows up in your keystrokes before you've finished typing. Type errors are the same story, one level up: the type checker catches them, cost is still near-zero, and they show up in seconds. Unit errors need fast local tests to catch. Now you're talking minutes. Integration errors need broader test suites, so minutes stretch to an hour. End-to-end errors need full-system tests: an hour to a day. Deployment errors are the release itself failing or misbehaving — hours to days, and by now users can usually see it too. Deployment results are subtler: the release works, technically, but the metrics move the wrong way, and that takes days to weeks to notice. Feedback is what users and customers actually say, and getting real signal there takes weeks. Business impact — revenue, retention, churn — needs a quarter or more to read clearly. And strategy update, the point where the org actually changes what it's doing based on everything above, can take quarters to years.

One honesty note before we go further: only the bottom half of this is "errors" in the strict sense, something demonstrably broke. Past deployment results, what you're actually tracking is information, a metric, a customer's own words, a board's decision, not a defect. We're keeping "ladder of errors" as the name anyway, because the bottom rungs are the clean, easy-to-picture case. But the same logic holds once "error" loosens into "signal you were wrong about something."

The reframe: it's a queue, not a gate

Here's the part that actually changes how you think about this. Each rung isn't one gate you pass or fail. It's a queue, a backlog of unverified work waiting for that rung's particular kind of check. A rung with a long queue behind it delays everything downstream of it, exactly like a factory station backed up with unfinished parts. You don't fix that by making the station faster. You fix it by not letting the queue build up in the first place, and we'll get into how in Part 2.

The same ladder, said in business language

This is the section doing the real work of the post, so walk it slowly. Same ten rungs, this time named the way an operator or a founder would name them, so a technical reader and a business reader end up looking at the exact same thing from the start.

Take a syntax error — that's a typo or a missing field, in a lead record, a contract, an invoice. A type error becomes a lead or a deal filed under the wrong stage or segment. The discount logic in your quote tool computing the wrong total for a known, fixed input? That's a unit error — something you can catch at a desk, no real customer involved yet. An integration error becomes a broken handoff: marketing to sales, sales to onboarding, support to product. End-to-end is a real prospect walking the whole funnel and hitting a gap nobody saw in isolation. Deployment failing looks like the campaign or the pricing change launching and something breaking immediately. Deployment results are subtler: the launch works, technically, while conversion, activation, or margin moves the wrong way. Feedback is what prospects, customers, and the people who just churned actually say. Business impact is revenue, retention, CAC, margin. And strategy update is the board or the exec team changing the plan.

One deliberate swap: a sales email that doesn't land isn't really the unit-test equivalent, because whether it lands depends on a real audience. A unit test checks something with no live audience at all, which is why the quote-tool example above is the closer match. A sloppy mapping is the fastest way to lose a technical reader's trust in the rest of the post.

Why cost tends to rise with altitude, and what the actual research says

Lower rungs are cheap to check because they're narrow and easy to automate. Higher rungs cost more because they need real-world exposure. You can't unit-test whether customers actually want the feature, and you can't A/B your way out of a bad market. That part's solid. But be careful what you cite to back it up.

Barry Boehm's old "cost of change" curve, the claim that a bug found late costs orders of magnitude more than one found early, had real data behind it, limited and TRW-specific, but real. What gets repeated everywhere in 2026 is a different, sharper claim wearing Boehm's name: " $1 in requirements,$ 10 in coding, $100 in testing,$ 1,000+ in production," usually credited to IBM or NIST. Laurent Bossavit's The Leprechauns of Software Engineering traced that specific dollar-figure version back over a decade ago and found no study anyone could point to that actually produced it, in at least one case the source Bossavit found showed the opposite ratio. The best real data we have instead is Menzies, Nichols, et al.'s "Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle" (Empirical Software Engineering, 2016), 171 real projects run between 2006 and 2014, the largest study of its kind. It found no consistent "delayed issue effect" at all. Fixing a bug late wasn't reliably more expensive than fixing it early.

So: treat "cost rises with altitude" as true, for the structural reason above, narrow-and-automatable versus needs-real-world-exposure. Not because of a $1-to-$ 1,000 multiplier that, as far as anyone's actually checked, doesn't hold up.

An engineering team pours effort into unit tests and CI while strategy runs on pure gut feel. A sales org instruments every dashboard on pipeline stages while nobody's tracked why the last three churned accounts actually left. It's the same gap wearing a different badge. Watch the top of the ladder as closely as you watch the bottom.

If each rung is a queue, the next question is which queue is actually the constraint. It's rarely the one everyone assumes, in a codebase or in a company. That's Part 2.

The ladder, rung by rung

The reframe: it's a queue, not a gate

The same ladder, said in business language

Why cost tends to rise with altitude, and what the actual research says

The same blind spot, two outfits

The Ladder of Errors: From Syntax to Strategy