There is a meeting that happens in every company sooner or later. The bill goes up, and a finance person asks a simple question. Why did our cloud cost jump this quarter? And the room full of engineers goes quiet. There are dashboards, there are tags, there are alerts. But there is no story. I have been in versions of that meeting more than once, and this post is my attempt to write the story I wish someone could tell in that room.
Here is the thing I believe more every year. Engineering choices are financial choices. When you pick a database, you are signing a contract with your future bill. When you pick serverless or a fixed server, you are choosing how your company pays for compute. Most developers never think about it this way. I did not either, for a long time. Back in my company in Brazil, we also managed the cloud for many of our clients, and the bill was always a real concern for our team. It is real money, and it deserves real thinking. The client should not have to pay extra for our bad choices, or for whatever technology was screaming the loudest in the market that year. Picking the expensive, fashionable option and sending someone else the invoice is not engineering, it is just following hype with a credit card that is not yours.
The two ways to pay for compute
Let me make it very simple. There are two basic models, and almost everything in the cloud is a mix of them.
The first model is fixed cost. You rent a server, or a cluster, or a reserved instance. You pay the same every month, no matter if your traffic is high or low. It is like rent for an apartment. Predictable, easy to budget, but you pay even when nobody is home.
The second model is pay per execution. Serverless functions, managed queues, some databases. You pay only when work happens. It is like a taxi. Cheap when you ride a little, expensive when you ride all day.
Neither one is better. The question is always the shape of your traffic. And this is where developers have power that finance people do not have. We know the shape.
A simple cost model you can do on a napkin
Here is the napkin math I use. Take one workload. Ask three questions.
First, how many executions per month, and how long does each one run? Multiply that by the serverless price. That is your taxi cost.
Second, what is the smallest fixed setup that can handle your peak? Price that out for a month. That is your rent cost.
Third, compare. If the taxi cost is way under the rent cost, go serverless. If the workload runs hot all day, every day, fixed cost wins almost every time. The crossover point is usually around steady utilization. A function that fires a few thousand times a day costs almost nothing. A function that replaces a server running at 70 percent all month will cost you several times more than the server.
This napkin is not perfect. It ignores egress, storage, and the time your team spends operating things. But it is good enough to have an adult conversation with finance, and that conversation is worth a lot.
Why this matters more than clean code
I know some people will not like this sentence, but I will say it anyway. A system that is a little ugly but costs half as much to run is often the better system. Martin Fowler has written for years, most directly in Is High Quality Software Worth the Cost?, about how architecture is really about the cost of change. I would extend that. Architecture is also about the cost of running. Both costs land on the same budget.
There is also a risk angle. Fixed cost is a bet that your traffic will stay. Pay per execution is a bet that it will not explode. I have seen a serverless bill jump 10x in one weekend because of a retry loop nobody noticed. With a fixed server, that same bug would have caused slow responses, not a surprise invoice. Slow responses are annoying. Surprise invoices get people fired.
How to have the talk
If you want to win trust with your CFO or your finance team, do not bring a dashboard. Bring three things.
A unit cost. Cost per order, cost per user, cost per donation processed. One number that connects the bill to the business.
A trend. Is the unit cost going up or down? The total bill growing is fine if the business grows faster.
One decision. Something like, we will move this batch job from a 24 hour server to a function that runs twice a day, and we expect to save this much per month. Small, concrete, measurable.
When engineers talk like this, something changes. Finance stops seeing the cloud bill as a black box and starts seeing the engineering team as people who care about the company money. That trust pays back later, when you need budget for the things that are hard to explain, like paying down tech debt or improving the test suite.
Start small (always)
Pick one service you own. Find what it costs per month. Divide by something the business understands. Then ask yourself the napkin questions. Maybe nothing changes. Maybe you find a server that has been running at 5 percent for two years.
The gray hairs I earned in this industry taught me that the developers who get trusted with the big decisions are the ones who understand that code runs on money. The bill is not the finance team problem. It is an output of our design, same as latency and same as bugs. Treat it that way, and the CFO talk becomes a talk you actually enjoy.
Pax et bonum.