👋 Hey {{first_name|there}},
Your architecture has a cost shape, whether or not anyone has drawn it. This week, the review card I use to find the line items nobody assigned to anyone, plus the story of the architect who used something like it to save his company $140,000 a year on a Wednesday afternoon.
Why this matters / where it hurts
I watched an architect save his company about $140,000 a year by reading the AWS bill line by line, on a Wednesday afternoon, while the rest of his team was in a planning meeting. He brought a printed copy. I had never seen anyone do that before, and I think I will remember it for a while. He had circled one line. NAT gateway egress is a little over $11,000 a month. He could not explain which decision had produced that number, and nobody else in the room could either.
That bill had been arriving for a year and a half. The architect of the system had changed twice during that time. The team had shipped four major features. Cost was on nobody's review checklist, partly because nobody owned it, and partly because architecture documents do not have a cost section. They have boxes and arrows. Cost lives in a different document, with a different audience, and the people designing the system rarely read the document that the people paying for it are reading. The gap between them is where most of the money quietly disappears, in my experience.
In Lesson #21 on SLOs and error budgets, we covered how reliability becomes a number you can spend down. Cost works the same way. Most teams I have seen have just not done the work to give it a number, and so it floats around the design unowned, like an undeclared dependency.
🧭 The shift
From: Cost is a finance problem, or a platform team problem, or a thing you clean up once a quarter.
To: Cost is a quality attribute. It belongs in the architecture review, on the same page as latency and reliability.
Reliability gets reviewed because it has SLOs and somebody on the hook for the p95. Cost usually gets reviewed once a quarter, after the bill arrives, by people who were not in the room when the architecture was decided. That timing alone is most of the problem. The team that wrote the cost into the system is not the team that finds it later.
The teams I have seen handle this well treat cost the way they treat latency. Every review answers, in writing, how much the proposed change will cost in steady state, what the per-request and per-customer impact looks like, and what the cleanup plan is if the assumptions turn out to be wrong. The teams that do not do this end up with one engineer reading the bill on a Wednesday afternoon. That is a fine fallback. The architect on the next system might not be that thorough.
A few defaults I now hold pretty firmly:
Treat cost as a non-functional requirement on every design doc, alongside reliability and performance. One paragraph minimum, with a number in it.
Tag everything you provision with a service dimension, a team dimension, and a customer or segment dimension. If a resource is not tagged, nobody is going to notice when it doubles in size.
Read the cloud bill once a month, with the architects in the room, not just finance. Half an hour. The first one is awkward. The third one starts paying for itself.
📘 Free Career Guide
The From Developer to Architect career guide just got a major update. It now includes a self-assessment rubric, a 90-day growth plan, architecture artifact templates, and interview prep frameworks. If you are working toward a Staff, Tech Lead, or Architect role, this is the structured roadmap.