step 25 / 32 · 5 min
Engineering decisions have a price
Every technical choice is also a financial and organisational one, and engineers who can talk about that are trusted with bigger decisions.
The bill
Cloud costs are usually dominated by a small number of things:
compute instances, and mostly idle capacity
storage volume, and how long it is kept
data transfer especially out of a region, or between them
managed things a premium for not operating it yourselfData transfer is the one that surprises teams. Moving data between availability zones or regions is billed, and a chatty service split across zones can cost more in transfer than in compute.
Build or buy
build: engineering time, forever, plus operating it
buy: a subscription, a dependency, and a vendor's roadmapThe mistake in both directions is ignoring the ongoing cost. Building an authentication system is a few weeks and then years of password resets, breaches and compliance. Buying one is a monthly bill and a migration if the vendor changes direction.
The reasonable rule: build what is your product, buy what is not. A payments company builds payments. Everyone else uses a provider.
Time is a cost
Six months building the perfect architecture is six months of not learning whether anyone wants the product. And a simpler system built now can be replaced; a complex one built now must be lived with.
This is the argument for the reversibility framing: spend effort on decisions that are expensive to undo, and keep everything else simple.
Technical debt
The metaphor is about interest. Taking a shortcut is borrowing time now against slower work later.
That is sometimes correct. Shipping to meet a real deadline and cleaning up afterwards is a legitimate trade, made deliberately.
It becomes a problem when it is invisible. Debt nobody records and nobody pays down compounds until every change is slow, and by then the case for fixing it has to compete with features on a roadmap where it looks like nothing.
Making the argument
| Weak | Stronger |
|---|---|
| "The code is messy" | "Changes here take three days instead of half a day" |
| "We should rewrite it" | "Two engineers, three weeks, and deploys stop failing" |
| "This does not scale" | "At current growth we hit the ceiling in four months" |
The second column translates engineering into the terms the decision is actually made in. Nobody rejects "changes take six times longer than they should"; plenty of people reject "the code is messy".