FinOps is not a tool problem

The myth of the right tool

When cloud costs get out of hand, the first reflex is almost always to look for the right tool that will finally get things under control. We could give you a name at this point and seemingly confirm that expectation, but honestly, we would not be doing you any favours.

Because a tool tells you what you spend, but not whether it is worth it. That second question is the one that really matters, and it cannot be bought, only answered.

The real first question

Before optimisation comes a decision that is surprisingly often never made consciously: how much may, and should, a product actually cost? Imagine someone building a factory without first talking about unit costs and margins, which would be unthinkable in the physical world. When running a product in the cloud, exactly that happens all the time, because resources create the illusion of being endlessly scalable, and because every bit of scaling lands on the bill immediately, without anyone having planned for it beforehand.

Asking this question turns the perspective around. It is no longer about pushing down a bill that is too high after the fact, but about deciding consciously up front where to invest because it benefits the product, and where not to. A cost statement you put up with becomes an investment decision you steer. That is what control means: not spending the least, but knowing what you are spending on and what it brings.

From the bill to the unit

For this question to be answerable, the absolute bill has to be related to a unit that fits the product. A cloud bill of USD 1,200 a month says nothing on its own. Only when you divide it by the 800 active users who actually used the product that month do you get a number you can work with: around USD 1.50 per active user. If the price is USD 15 a month, infrastructure accounts for roughly ten per cent, and the real question is no longer “Is 1,200 a lot?” but “Does this share stay stable as we grow?”.

Which unit is the right one depends on the product. For a multi-tenant product, it is often worth looking at the cost per tenant, which bundles several users, because a single large tenant strains the structure quite differently from many small ones. For other products, a view per transaction is conceivable, although that quickly becomes abstract and is rarely the best starting point. The mature goal behind it is a proper unit economics view, as the FinOps Foundation describes it, which brings together cost, usage and revenue per unit. That is the direction, but honestly not the first step.

The honest first step

Before costs can be cleanly allocated to units, there is a less spectacular piece of work that is almost always skipped in practice. First you have to know which contracts exist at all, because next to the big cloud bill there are often further recurring items with other providers hiding that nobody has ever looked at together. Then you have to understand which systems are actually paid for through these contracts, because a contract name rarely reveals which service runs behind it for which product.

Just as important is the question of who is responsible for each of these items, because a cost item without a responsible person is never steered consciously, it simply keeps running. And finally, for each item you can ask what it actually contributes to the overall system: whether it carries a product, enables growth or covers a risk, or whether it is only there for historical reasons. Only once these four things are clear does a bill become a map on which units and investment decisions can be placed at all.

Where tools help and where they don’t

To avoid a false impression: for standard problems, standard tools are often exactly right. If you have a recurring question for which an established tool exists, use it instead of reinventing the wheel. A tool, however, only ever measures what you tell it to, and none of them will decide for you that cost per active user is what matters. That decision is the actual work, and a tool only becomes useful after it.

The really exciting part of today’s technical world lies elsewhere, though. As soon as the cost data sits in a clean, standardised foundation, it can be connected to a language model and thereby explored, instead of only being viewed in ready-made dashboards. You ask a question, see the answer, and the next question follows from that answer, without anyone having had to set up a matching tile beforehand. That is where a great deal of potential lies today, because the data becomes as flexible as thinking about it already is.

The first concrete step

Setting up this data foundation is smaller than most people expect. AWS, GCP, Azure and OCI all now support the FOCUS format, a uniform standard for billing data across all providers. Enabling it takes hardly any effort and immediately creates a clean, standardised basis on which every further analysis builds. For a company with its own product in the cloud, this is the lowest-threshold first step towards real control over its own numbers.

What grows out of this foundation when you connect it through a local DuckDB via MCP to a language model and query it in natural language is described in detail in the article Talking to your own numbers. Here it is enough to keep in mind that the foundation is the beginning, not the goal.

Where the impact comes from

The real value does not come from the data itself, but from the moment data turns into information that makes a difference. Only then can the investment question be answered for each product, and only then does a gut feeling become a decision you can justify and review over time. In our practice it shows again and again that this view of costs rarely stands alone, but is closely interwoven with security, operations and organisation, because in the end the same data foundation and the same maturity carry all of these topics.

The best next step is therefore not a purchase but a conversation: ask within your own company how much each product may cost, and in parallel enable the FOCUS export so you have a foundation in the first place. If you want someone at your side who is knee-deep in the subject, we are happy to sort it out together with you.