Every FinOps hire is a symptom. It means that at some point, probably across many points, a team built something without asking what it would cost to run at production scale. The FinOps practitioner exists to compensate for that gap after the fact. And after the fact is the most expensive time to fix anything in software.
This is not a criticism of FinOps practitioners. The people doing this work are genuinely good at what they do — cost allocation, reservation management, anomaly detection, chargeback modelling. These are real skills applied to real problems. But the discipline only exists because those problems were created upstream, and nobody stopped to ask the right question before the architecture was committed. That is where I have a problem.
Cost is a system requirement. It belongs in the design conversation alongside latency, availability, and security. If you would not accept “we’ll think about reliability later” as an answer in an architecture review, you should not accept “we’ll think about cost later” either. The two are the same type of deferral. One just produces incidents. The other produces invoices.
Related reading: The distinction between how we frame cost problems matters. See Stop Calling It Cloud Waste. It’s Architecture Debt. to understand why the label you use shapes the fix you reach for.
The Design Deadlock: I once walked into a project mid-development where the PM was desperate to reduce the bill. The problem? The architecture had already been signed off with a Data Warehouse at the core. We were already on the lowest possible SKU, so there was no “magic button” to click. Because cost wasn’t a constraint during the design phase, we were backed into a corner where our only lever was a manual one: aggressively turning off instances the second active development or testing stopped. If cost had been a Day 1 requirement, we might have chosen a different data pattern entirely.
The structural analogy I keep coming back to: if a civil engineer submitted a bridge design without calculating material costs, we would not hire a specialist to “manage the material spend” after the bridge was built. We would ask why cost was not in the original design.
Material Costs and Intentionality: In my experience, the biggest “material cost” is simply not SKUing the instance correctly. I recently looked at a Container Apps environment where every container was assigned 2 vCPUs by default. After some testing, I dialed them down to 0.1 vCPU per container. The performance didn’t move an inch, but the bill plummeted. This happens because architects often design for “what sounds safe” rather than “what the workload actually needs.”
The FinOps industry exists because cost discipline in architecture is not universal. I understand why the discipline exists. I just do not think it is the right long-term answer. Sometimes, you have to get creative with the architecture to save the budget—like designing a pattern where heavy data processing happens in a single cost-effective region, and then shipping the final results to reside where they are legally required.
The goal is not a better FinOps practice. It is an architecture practice where FinOps is unnecessary. The right long-term answer is architects who treat cost as a first-class design constraint — who can say, in an architecture review, “this pattern will cost approximately X to run at this scale, and here are the trade-offs of the cheaper alternative.” That is a skill. It is learnable. And it is currently undervalued.
A design that does not model its running cost at production scale is an incomplete design. Full stop.
