Skip to content

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:

code
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 yourself

Data 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

code
build:  engineering time, forever, plus operating it
buy:    a subscription, a dependency, and a vendor's roadmap

The 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

WeakStronger
"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".