FinOps 101: the discipline every scaling company eventually needs

01.What FinOps is, and is not

FinOps is a way of working, not a tool. It treats cloud cost as a shared responsibility. Engineers decide what to build and how. Finance plans and reports. Product decides what is worth spending on. FinOps connects them through shared data and a regular rhythm.

It is not a one-off cost-cutting exercise. A project can reduce the bill once. A practice keeps it from drifting back.

It also is not about spending less at any price. The aim is to spend well. Sometimes that means spending more on a feature that earns more.

02.The three phases: inform, optimise, operate

The loop has three phases, and teams move through them repeatedly.

Inform: see the spend. Before you can improve anything, you need to know where money goes. That means tagging resources, allocating costs to teams and products, and building reports people actually read. A good inform phase answers: who spends what, on which service, and is it growing?

Optimise: remove waste. Once you can see the spend, act on it. Remove idle resources, rightsize oversized ones, move storage to cheaper tiers, schedule non-production environments and plan commitments such as reserved instances or savings plans. Start with the safe changes and the large ones.

Operate: make it routine. Optimisation fades if nobody keeps at it. The operate phase builds the habits: budgets by team, anomaly alerts, a monthly review, forecasting and clear owners. New projects include a cost estimate. Savings are tracked and credited.

03.Start with three things

You do not need a large team or a long programme to begin. Start with:

• Tagging. Agree a small set of tags: owner, team, product and environment. Apply them to new resources by policy, and backfill the biggest existing ones.
• A monthly review. One hour, finance and engineering together, looking at spend by team, the biggest changes and the next actions.
• One owner per major cost area. Compute, storage, data and AI spend each get a named person who can explain the number.

These three habits cover most of the early value.

04.An example of the loop

Imagine a company whose bill rose by a fifth in a quarter. In the inform phase, they find that a third of spend has no owner tag, and that one analytics team's storage is growing fast. In the optimise phase, they add retention rules and remove unused snapshots, then stop idle test clusters. In the operate phase, they set a budget for the analytics team, add an alert for daily storage growth and review it monthly. Next quarter the loop repeats with a smaller, more targeted list.

05.A first month in detail

Week one: collect the data. Turn on detailed billing exports, list all cloud accounts and subscriptions and identify who pays for each. Do not try to fix anything yet.

Week two: find the big numbers. Rank services by spend, rank accounts by spend and measure the share without tags. Pick the top five items and ask who owns each.

Week three: agree tags and owners. Keep the list short. Add a policy that new resources need the tags, and start a weekly report of untagged spend.

Week four: hold the first review. Look at the numbers together. Choose three actions with owners and dates. Write them down. Repeat next month and add one new habit each time.

06.Metrics worth tracking

Total spend alone hides too much. Track a small set of ratios that connect cost to the business.

• Cost per customer or per transaction. It shows whether you are scaling efficiently.
• Percentage of spend tagged and allocated. It shows how much you can explain.
• Non-production share of spend. It shows how much goes on testing.
• Commitment coverage. It shows how much steady usage is covered by a discount.
• Forecast accuracy. It shows whether finance can trust engineering's plans.

Pick the few that matter to you. A metric nobody acts on is decoration.

07.Culture matters more than tooling

The hardest part of FinOps is not technical. Engineers need to feel that cost is part of good design, alongside reliability and security, not a tax imposed from outside. That happens when leaders ask about cost in design reviews, when savings are recognised and when engineers are given the data and trusted to act.

08.Who does what

• Engineering: owns usage and responds to findings.
• Finance: owns budgets, forecasts and reporting.
• Product: weighs cost against value and prioritises.
• Leadership: sets expectations and removes blockers.
• A FinOps lead or champion: runs the rhythm. In small companies this is part-time.

09.A short example of the operate phase

Suppose a product team plans a new feature that stores user uploads and runs image processing. In an operating FinOps practice, the team estimates monthly cost before building: storage growth, processing hours and data transfer. The estimate goes into the design review. After launch, the dashboard shows actual cost against the estimate. If it is higher, the team looks at why, perhaps files are stored at full size when thumbnails would do, and fixes it early.

Compare that with the usual pattern, where the cost is discovered on the next invoice and nobody remembers the design.

10.How to know it is working

After a few months, you should see these signs: the share of untagged spend is falling, cost alerts reach the right people and are answered, the monthly review has an agenda and actions, forecasts are closer to actual and engineers mention cost in design discussions without being asked. If those are happening, you have a practice. If they are not, return to the inform phase and check the basics.

Expect the first review to be uncomfortable. That is normal. It means the numbers are finally visible.

11.Common mistakes

• Buying a tool and stopping there. Tools show data. People change behaviour.
• Blaming teams. Show the cost, explain the context and ask for ideas. Blame ends the conversation.
• Skipping the inform phase. Optimisation without attribution is guesswork.
• Over-committing early. Commitment discounts help only if you will keep running the workload.
• No link to product decisions. Cost per customer or per feature is more useful than a total.

Keep the first version of everything small. A one-page tag standard, a one-hour meeting and a list of owners is enough to begin. You can add tooling once the habits exist, and the tooling will then fit how you work.

Review the setup after a quarter and adjust. Drop any report nobody reads and add the one people keep asking for.

12.What to do next

This month: agree a tag standard, name the owners and put the first review in the calendar. Next quarter: add budgets and alerts, and begin to plan commitments. Within a year, it should feel like part of how you run engineering.

Brandsmashers sets up FinOps practices for teams that want the benefit without the overhead: tagging, dashboards, savings work and the review routine that keeps it going. If you would like to start small and see results, book a call and we can plan the first month.