The managed service costs £3,000 per month. Building it costs four engineer-weeks. Do the maths for the next three years.
You already know the arithmetic. Four engineer-weeks at loaded cost is roughly £30,000. Three years of the managed service is £108,000. The spreadsheet says build. The spreadsheet is wrong. It measured the wrong thing.
This is AT7 — Automation vs Control. It is not a cost decision. It is a decision about which decisions your team wants to keep making, and which ones the system should make on its own.
What AT7 actually dials
An automated system makes decisions without human intervention. Faster. More consistent. Never tired. A controlled system defers decisions to humans. Slower. But human judgment enters when the situation is novel.
Auto-scaling based on CPU utilisation is automated. A pager alert asking an on-call engineer to add capacity is controlled. Automated deployment pipelines are automated. Manual deploy approvals are controlled. Automated fraud detection is automated. Human fraud review is controlled.
Build-versus-buy is the same dial pointed at your infrastructure. A managed service is automation you rent. Someone else runs the failover, the patching, the capacity planning, the compliance audits. A system you built is control you own. Every operational decision comes to your team.
The decision is not "spend money" versus "save money." The decision is "let the vendor decide" versus "we decide."
The side you are told to pick
Buying looks obvious in the pitch deck. The vendor has run this service for ten thousand customers. Their on-call rotation exists. Their runbooks exist. Their compliance certifications exist. You get all of it on day one.
Routine decisions with clear criteria set toward automation. Managed Postgres is a routine decision. The vendor patches faster than you will. The vendor's failover is more tested than yours will be. Buying is the right answer for the same reason auto-scaling on CPU is the right answer — the decision is repeatable, the criteria are clear, and the automated system will make it better than a human on a Tuesday afternoon.
This is why the default answer for most infrastructure in most companies is buy. The vendor is running an automation. You are renting it. The rent buys you back the engineer-weeks you would have spent making the same decisions worse.
The side the spreadsheet hides
Novel situations with ambiguous criteria set toward control. This is where the spreadsheet lies.
The managed queue serves your team well for eighteen months. Then a product decision requires message ordering semantics the vendor does not support. Now you have three options. Rewrite the product decision around the vendor. Migrate to a different vendor. Build the missing behaviour on top. Each option costs more than the four engineer-weeks you saved.
High-stakes irreversible actions set toward control. Automated database failover is acceptable. Automated data deletion is not. The same rule applies to buying: rent the routine, own the load-bearing. If a vendor outage stops your revenue for four hours, you did not save money. You paid for the outage in a currency the spreadsheet does not track.
Automation amplifies both correct and incorrect decisions. When you buy, you are amplifying the vendor's decisions across your entire system. If the vendor is right, you win at their scale. If the vendor is wrong, you lose at their scale.
The failure mode the decision exposes
FM3 — Unbounded Resource Consumption. The wrong choice on AT7 exposes it from either side.
Build the wrong thing and the resource that grows without bound is engineering time. The internal queue works. Then it needs monitoring. Then it needs a retry policy. Then it needs dead-letter handling. Then it needs a UI. Then the engineer who built it leaves. Every quarter the system takes more people to keep alive. The initial four engineer-weeks becomes a permanent tax on the team. The tax compounds because the people paying it are the same people you need for the next product decision.
Buy the wrong thing and the resource that grows without bound is your bill. Usage-based pricing on a component in your hot path grows with your traffic. You optimised the build cost and left the operating cost open-ended. At small scale it is invisible. At the scale where the product works, it is a line item that will not shrink.
The failure is symmetric. Either side of AT7 can produce FM3. The question is which side you are equipped to bound.
The signal that tells you which side to pick
The decision reduces to three questions the spreadsheet never asks.
Is this a routine decision or a novel one? If the criteria are clear and the same decision recurs, the vendor's automation will beat yours. Rent it. If the criteria are ambiguous and every instance is different, keep the decision inside the team. Build it, or buy a component and keep the decision layer.
Is this on the critical path of your product's differentiation? If your product wins because this component is better than anyone else's, you cannot rent that advantage. The vendor sells the same automation to your competitor. If the component is table stakes — everyone has it, no customer chose you for it — buying is correct.
Can you bound the cost on the side you chose? Building means bounding engineer time. Buying means bounding the bill. Neither bound is free. If you cannot describe how you will bound the cost you are taking on, you have not made the decision yet. You have deferred it.
The three-year cost the spreadsheet missed
Return to the opening arithmetic. Four engineer-weeks versus £108,000 over three years.
The spreadsheet counted the build cost as four engineer-weeks. The real build cost is four engineer-weeks plus every incident, every migration, every on-call page, every knowledge transfer for the next three years. Call this number X. Nobody knows X in advance. The team that built it discovers X one quarter at a time.
The spreadsheet counted the buy cost as £108,000. The real buy cost is £108,000 plus every product decision you shape around the vendor's constraints, every hour spent on integration when their API changes, every incident their status page did not update fast enough. Call this number Y. Nobody knows Y in advance either.
AT7 is the choice between paying X and paying Y. Neither is the number in the pitch deck. The engineering skill is estimating which one you can bound, and choosing that one.
The signal in your own system
Look at your last four architecture reviews. Count the components where someone said "we built it because the managed version was too expensive." Now count the ones still owned by the original author. If the second number is smaller than the first, you are paying X and did not know it.
Or look at your vendor bill. Find the line item that grew fastest last year. Ask whether your team can describe the ceiling. If nobody can, you are paying Y and did not know it.
Both signals mean the same thing. The AT7 decision was made once and then never revisited. Automation dials are not set once. They are re-checked whenever the requirement that set them changes.
The full framework treatment — compression blocks, three-level exercises, and the complete AT/FM mapping — is in the Reference Book, Chapter 8 (Architecture Tradeoffs). Free chapter available at computingseries.com/books/ref.