Before the build
The most expensive technical decisions often happen before engineering starts.
Deciding to build is the decision
By the time a team is estimating a build, the expensive choice has usually already been made — the choice that this is worth building at all. Estimates argue about weeks. The decision that precedes them commits the business to owning a system for years.
The question is rarely whether something can be built. It almost always can. The useful question is what happens to the business once it exists.
Build is a commitment, not a task
Anything you build, you own: you maintain it, staff it, secure it, document it, and eventually migrate or retire it. That cost does not appear in the estimate. It appears in the second year, when the person who wrote it has moved on and the thing still has to work.
The alternatives are not free either
Buying trades control for speed and adds a dependency. Automating narrows a problem rather than solving it. Deferring keeps the option open at the price of living with the current friction a while longer. None of these is always right, but naming them turns one option into a real choice.
What we look for
Which assumption is doing the most load-bearing work, and whether it has actually been tested. What breaks if the decision turns out wrong, and how expensive that reversal is. Where complexity would compound quietly — the integrations, edge cases, and operational handoffs nobody costs up front.
Sometimes the answer is not to build
A recommendation not to build is not a failed engagement. It is often the highest-return decision available, because the cheapest system to operate is the one you never had to write.