Faced with two methods that nominally do the same job at different costs, the rational-seeming move is to take the cheaper one until it proves inadequate. This is often right, but it hides a trap. The cheaper method is usually cheaper because it does less work, and “less work” frequently means “discards some information along the way.” If the information it discards is irrelevant to your problem, the savings are free. If it’s the exact thing your problem depended on, the savings are an illusion that you’ll pay for later in failures you can’t easily diagnose.

The classic shape is a method that flattens a rich representation into a simpler one before processing it. The flattening is what makes it fast and cheap. But flattening is lossy by definition — it throws away structure to gain simplicity, and the structure it throws away is sometimes load-bearing. A process that reduces a spatially-arranged document to a flat stream of text is cheaper than one that preserves the layout, and for problems where only the words matter, that’s a fine trade. For problems where the arrangement carries meaning — where what’s in which column and row is the entire point — the cheap method has discarded the answer before processing even begins.

What makes this trap hard to see is that the cheaper method doesn’t fail loudly. It produces output. The output looks plausible. It’s only wrong in the specific cases where the discarded structure mattered, and those cases may be a minority that don’t show up in casual testing. So the cheaper method passes the quick evaluation, gets adopted, and then quietly produces wrong results on exactly the inputs that were the reason the tool existed. The failure is correlated with the hard cases, which are the cases that matter most, which is the worst possible place for failures to hide.

The defense is to ask, before choosing a method on cost, what each method discards to achieve its price. Every optimization has a “by doing less of what” hiding behind it, and naming that explicitly turns an invisible trade into a visible one. Once you can say “the cheap method works by throwing away X,” you can ask the only question that matters: does my problem depend on X? If it doesn’t, take the savings with confidence. If it does, the cheaper method was never actually solving your problem; it was solving a similar-looking problem that happens not to need X, and the resemblance was misleading you.

This reframes the build-versus-cost decision in a useful way. The expensive method is not expensive for no reason — it’s preserving something, and you’re paying for that preservation. The right question is not “can I get away with the cheaper one” but “is what the expensive one preserves something I need.” Sometimes the answer is no and you’ve saved real money. Sometimes the answer is yes and the expensive method was never optional; it was the only one that actually addressed the problem, and the cheaper alternative was a detour that would have cost more in the end through failures, debugging, and the eventual switch you should have made at the start.

The general principle is that cost differences between methods are rarely free lunches; they are usually trades, and the thing being traded away is information or fidelity that may or may not matter to you. Treat a suspiciously cheap method as a question rather than a gift: what does it not do that the expensive one does, and do I need that thing? Answer honestly, and the cost comparison becomes a real decision instead of a default toward cheap that quietly mortgages your hardest cases.