The hidden cost of technical decisions

The price of a technical decision is almost never the one on the invoice.

It is what the decision does to every decision that comes after it

Take a framework chosen because the team knew it. The visible cost is zero: no training, no hiring. The hidden cost shows up two years later, when nobody wants to join a project on a stack the market has left, and every migration estimate starts with “first we would have to”.

Take a shared database between two services, chosen because it was quicker than an API. The visible cost is a week saved. The hidden cost is that the two services can never again be deployed, scaled or changed independently, and that every schema change is now a negotiation.

Take a library added to save an afternoon. The visible cost is an afternoon. The hidden cost is a dependency to update, a vulnerability to track, an upgrade that one day breaks the build on a Friday.

None of these choices is wrong in itself. What makes them expensive is that they were taken as if they were free, with no one asking the only question that matters: what does this make harder later, and who will pay for it?

I have come to ask three things of any technical decision that will outlive the sprint. Name the option we are giving up. Name the moment we would want to reverse it. Write both down where the next person will find them.

It takes ten minutes, and it is the cheapest architecture work I know