If you run infrastructure for a 20 engineer startup and somebody has just sent you a link to the FinOps Framework, the short answer is that you need about a quarter of it and you can run that quarter well. The FinOps Framework describes the full practice of an organisation with a dedicated FinOps team, and you do not have one. You have one person who already owns deploys, on-call and security, and who now also owns the cloud bill.
Most writing about this framework gets one of two things wrong. Either it presents the whole model as a checklist to adopt in order, which produces a 20 engineer team documenting a chargeback policy for a company with one cost centre, or it presents the framework as a reason to buy a platform. Neither tells you which parts pay for themselves at your size.
So this post names the parts, puts an hours-per-month number against each one at roughly 20 engineers, and says which capabilities to start now and which to pick up on a specific trigger. Every structural claim is sourced to the FinOps Foundation or to Microsoft Learn. Every hours figure is a practitioner estimate and is labelled as one inline, because no published benchmark gives effort by team size.
Quick context: what cloud FinOps looks like going into 2026
Two numbers from the Foundation's own State of FinOps 2026 survey set the scene. The share of respondents managing AI spend reached 98 percent, up from roughly a third two years earlier. And self-reported cloud waste rose to 29 percent, the first increase in five years.
That second number is the interesting one. Waste rose in a discipline whose purpose is to bring it down, because new services and AI workloads arrived faster than the governance around them. The practitioner reading: this is not a knowledge gap, because the published guidance has never been better. Spend simply moved into places the existing process did not cover.
Meanwhile the scope of cloud FinOps widened. It started as public cloud cost management and now explicitly covers SaaS, data centre, data cloud platforms and AI. That is why the framework feels heavier every year, and most of the added weight answers a problem a 20 engineer team does not have yet.
Takeaway: the framework grew in 2026 in a direction that mostly serves large estates. Read it knowing you are choosing from a catalogue, not following a sequence.
What the FinOps Framework actually is
The FinOps Framework is the FinOps Foundation's published model for how an organisation manages variable technology spend. It is a vocabulary and a map: it names the work, groups it, and gives you a way to say how far along you are. It is not software, not a certification requirement, and not a sequence you are expected to complete.
Four parts of it are worth knowing by name, per the Foundation's framework overview:
- Phases. Inform, Optimize and Operate. A loop rather than a project: see the spend, act on it, keep the rhythm going.
- Domains. Four groupings of work: Understand Usage and Cost, Quantify Business Value, Optimize Usage and Cost, and Manage the FinOps Practice.
- Capabilities. The individual activities inside each domain, such as allocation, forecasting or rate optimization. These are the units you actually adopt.
- Maturity. Crawl, Walk and Run. An explicit scale, which matters more than it sounds: Crawl is a maturity state, not a failing.
Two further pieces sit alongside those. Personas describe who the work touches, from engineering to finance to leadership. Scopes and Technology Categories describe which kind of spend you are applying the framework to. The FinOps definition itself was revised in the 2026 edition to match the Foundation's broader mission, which is the clearest signal that this is a living document rather than a standard you comply with.
Takeaway: the framework gives you names for work you are already doing, or not doing. That alone is worth the read, before you adopt a single capability.
The three phases, and what each one costs you at 20 engineers
The phases are the easiest part to adopt, because you are already partway through them whether you use the words or not. Microsoft Learn's framework overview describes the same three-phase loop as the Foundation does.
Inform. Get the spend visible and attributed. At 20 engineers this is a tagging or labelling convention, one cost dashboard, and knowing which three services make up most of the bill. Practitioner estimate: 4 to 8 hours to set up, then 1 to 2 hours a month to keep honest.
Optimize. Act on what Inform showed you. Rightsizing, deleting idle resources, moving storage classes, buying commitments on the steady base. This phase is bursty rather than steady. Practitioner estimate: 8 to 16 hours for a first proper pass, then 2 to 4 hours a month.
Operate. Keep the loop running and tie it to a decision. At your size this is one recurring half hour where somebody looks at the trend and the anomalies, plus the budget alert that fires when it matters. Practitioner estimate: 1 to 2 hours a month.
Added up: a first month of roughly 15 to 25 hours, then a steady state of 4 to 8 hours a month. The steady state is the number that decides whether this survives a product roadmap. If your cost programme costs a day a month to run, it gets dropped the first time a release slips.
Takeaway: budget the setup burst honestly and keep the steady state under half a day a month, or the loop will quietly stop after six weeks.
The four domains, and which capabilities a small team can carry
Domains group the capabilities. The Foundation's domains page and the Microsoft Learn capabilities index agree on the four names and are the two places to check current naming, because capability names moved in the 2026 edition.
- Understand Usage and Cost. Data ingestion, allocation, reporting and analytics, anomaly management. This is the data layer and it is where a small team gets the most per hour.
- Quantify Business Value. Planning and estimating, forecasting, budgeting, benchmarking, unit economics. Mostly finance-facing. One earns its place early and the rest arrive with your first board deck carrying a margin line.
- Optimize Usage and Cost. Architecting and workload placement, usage optimization, rate optimization, licensing and SaaS, cloud sustainability. This is where the money actually moves.
- Manage the FinOps Practice. Practice operations, education and enablement, policy and governance, invoicing and chargeback, assessment, and the new Executive Strategy Alignment. This domain is about running a team that does FinOps, the part you are deliberately not building yet.
The answer falls out of that list. Three domains contain work a single engineer can do in an afternoon. The fourth describes the organisation around the work, and at 20 engineers that organisation is one person and a founder who can be interrupted.
Takeaway: read the domains as four difficulty tiers, not four workstreams. Start inside Understand Usage and Cost and Optimize Usage and Cost, and treat the practice domain as reading material.
What the 2026 edition changed
The Foundation published its 2026 revisions with the headline Executive Strategy, Technology Categories, and Converging Disciplines. Four changes matter for how you read the current docs.
- A new capability, Executive Strategy Alignment, in the Manage the FinOps Practice domain. It is organised around executive priority alignment, multi-year investment strategy, product prioritisation and strategic decision support.
- Renamed capabilities. Workload Optimization is now Usage Optimization, so an older article and the current site will disagree on the name of the same work.
- Technology Categories. Dedicated pages for public cloud, SaaS, data centre, data cloud platforms and AI, which is how the Scopes idea became concrete.
- Converging disciplines. Explicit treatment of where FinOps overlaps neighbouring practices rather than pretending it owns the ground alone.
Worth saying plainly: Executive Strategy Alignment exists because in a large company the FinOps team and the people who set the multi-year budget rarely meet. At 20 engineers they are the same two people and they talk daily. You already have the outcome that capability is designed to produce.
Takeaway: when you read a capability, ask which organisational problem it solves. If your org chart already solves it, you have that capability and can move on.
The six capabilities to run now
These six give you most of the available return at 20 engineers and fit inside the hours budget above. Estimates are mine, not published figures.
- Allocation. A tagging convention that survives contact with reality: owner, environment, service. Three tags enforced beats twelve tags aspired to. Setup 3 to 6 hours, then near zero if you enforce it at the infrastructure-as-code layer.
- Reporting and analytics. One dashboard somebody actually opens, showing spend by service and by the tags above. Setup 2 to 4 hours, then 30 minutes a month.
- Anomaly management. One alert that fires when daily spend breaks its own pattern. The highest-value hour in the list, because it turns a month-end surprise into a same-week question. Setup 1 to 3 hours.
- Rate optimization. Commitments on the base load you are certain of, and nothing more. Setup 2 to 4 hours, revisit quarterly.
- Usage optimization. Rightsizing, idle resources, storage lifecycle, non-production shutdown schedules. Setup 6 to 12 hours, then 1 to 2 hours a month.
- Budgeting. One number for the month and an alert at 80 percent of it. Setup 1 hour.
Two of those overlap heavily with work we have written up separately. The mechanics of the first optimisation pass are in how to reduce cloud costs at a seed stage startup, and what a structured review turns up is in what a cloud cost audit actually finds.
Takeaway: if you only have three hours this quarter, spend them on anomaly management. Everything else can wait a month without costing you money; a silent spend spike cannot.
What waits, and the trigger that brings it in
Sequencing is the framework working as designed. Crawl is a maturity state, not a failing, and the Foundation says so by building the scale into the model. The six above run now. The ones below wait for a trigger, and the trigger is named here, because naming it is what stops it being forgotten.
- Unit economics. Brings cost per customer or per transaction into the conversation. Trigger: your first pricing revision, or the first investor question about gross margin.
- Forecasting. Beyond reading the trend line. Trigger: a commitment purchase large enough that being wrong by a quarter costs real money.
- Benchmarking. Comparing your ratios against peers. Trigger: twelve months of clean allocated data.
- Invoicing and chargeback. Pushing cost onto internal owners. Trigger: a second business unit, or a customer-facing pass-through.
- Cloud sustainability. Carbon alongside cost. Trigger: a procurement questionnaire that asks.
- FinOps assessment and practice operations. Formally scoring and running the practice. Trigger: a dedicated owner whose main job this is.
Write those triggers next to the quarterly review. A capability you deliberately sequenced is a decision; the same one forgotten is a surprise six months later.
Takeaway: record the trigger, not just the decision. The trigger is what converts "later" into something that actually happens.
FOCUS, the piece that pays off even with no practice at all
One output of the FinOps Foundation is worth adopting regardless of how much of the framework you run. FOCUS, the FinOps Open Cost and Usage Specification, is an open schema for billing data so that cost and usage from different providers arrive in the same columns with the same meanings. The specification overview explains the intent and the specification page carries the current version, 1.4, ratified in June 2026.
Its history is short and fast. Version 1.0 reached general availability, 1.2 extended it to SaaS and PaaS billing and invoice reconciliation, and later versions deepened commitment data and data-integrity rules. Provider support has followed, which is what makes it useful rather than aspirational.
Why this matters at 20 engineers has nothing to do with multi-cloud ambition. A query written against FOCUS columns keeps working when you add a provider, change cost tools, or hand the dashboard to someone else. You buy portability for the cost of reading a schema.
Takeaway: when you build the one dashboard, build it on FOCUS-shaped columns if your provider exports them. It is the same hour of work and it survives your next tooling change.
FinOps tools versus FinOps software versus a spreadsheet
Searches for finops tools and finops software mostly land on the same market: cost platforms that ingest your billing data and present allocation, forecasting and optimisation recommendations. The difference that matters is not between those two labels. It is between a platform, your provider's native tooling, and a spreadsheet with a monthly export.
| Option | What it gives you | What it costs | Fits when |
|---|
| Provider native tooling plus a spreadsheet | Allocation, budgets, anomaly alerts, a monthly export you can pivot | Included in the bill, plus your hours | Single provider, under roughly 20,000 US dollars a month of spend |
| Native tooling plus one open-source or scripted layer | The above, plus custom allocation logic and automated reports | Engineering time to build and own it | One provider but messy allocation, or a second account estate |
| A commercial FinOps platform | Multi-provider normalisation, unit economics, chargeback, recommendations | Licence, commonly a share of monitored spend, plus onboarding | Multiple providers or enough spend that a few percent saved exceeds the licence |
The decision rule. Compare the platform's annual cost against a realistic saving on the spend it would watch. If the licence costs more than a few percent of that spend, native tooling plus your own hours wins on arithmetic, and those hours teach you where the money goes. Revisit when you add a second provider, because normalising two billing formats by hand is exactly what these platforms do well.
Provider-native automation is moving quickly in this space too, and we looked at one example in what the AWS FinOps agent does and what it costs.
Takeaway: at 20 engineers on one provider, native tooling plus a disciplined spreadsheet is usually the right answer, and the trigger to revisit is a second provider rather than a bigger bill.
The honest summary table
Practitioner estimates, 20 engineers on one provider. Setup is one-off, ongoing is per month.
| Capability | Domain | Setup | Ongoing | Verdict at 20 engineers |
|---|
| Allocation | Understand Usage and Cost | 3 to 6 hours | Near zero if enforced in code | Run now |
| Reporting and analytics | Understand Usage and Cost | 2 to 4 hours | 30 minutes | Run now |
| Anomaly management | Understand Usage and Cost | 1 to 3 hours | Minutes per alert | Run now, highest value per hour |
| Rate optimization | Optimize Usage and Cost | 2 to 4 hours | Quarterly review | Run now |
| Usage optimization | Optimize Usage and Cost | 6 to 12 hours | 1 to 2 hours | Run now |
| Budgeting | Quantify Business Value | 1 hour | Minutes | Run now |
| Unit economics | Quantify Business Value | Days | Hours | Wait for a pricing revision or a margin question |
| Forecasting | Quantify Business Value | Days | Hours | Wait for a large commitment purchase |
| Invoicing and chargeback | Manage the FinOps Practice | Days | Hours | Wait for a second business unit |
| Executive Strategy Alignment | Manage the FinOps Practice | Ongoing | Ongoing | Already covered by your org chart |
Stage-specific recommendation
Pre-seed, under 10 engineers. Two capabilities: anomaly management and budgeting, roughly two hours of setup. Leave the vocabulary for later and come back to the framework when somebody asks you to explain your cost process. The whole return at this stage is finding out quickly when the bill moves.
Seed, 10 to 30 engineers. The six in the table above, in that order, over a quarter. Add tagging enforcement in your infrastructure-as-code so allocation stays true without anyone policing it. This is where the framework's vocabulary earns its keep, because more than one person now makes spend decisions and they need the same words.
Series A, 30 to 80 engineers. Keep the six, add forecasting and unit economics, and read the Manage the FinOps Practice domain as a description of the role you are about to need. This is also where a commercial platform starts clearing the arithmetic bar, especially with a second provider in the estate.
If you want a second opinion on which six to run
MatrixGard runs a free 20-minute cloud cost review for early-stage founders and engineering leads. Your current bill shape, which of the six capabilities would pay back fastest on your estate, and an honest read on whether you need anything beyond native tooling. The standalone cloud cost audit is 35,000 rupees or 3,000 US dollars, and the Starter retainer is 30,000 rupees or 2,500 US dollars a month, both published on the pricing page. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for early-stage startups, funded or bootstrapped, across India, the GCC, the UK and the US. Almost a decade building, breaking and securing cloud infrastructure for fintech, healthtech and SaaS workloads.
Methodology note. Framework structure, domain names, phases, maturity scale and the 2026 revisions are taken from the FinOps Foundation framework, its domains pages and the Foundation's 2026 framework announcement, cross-checked against Microsoft Learn's capabilities index. Survey figures come from the Foundation's State of FinOps 2026. FOCUS version and scope come from the FOCUS specification site. Capability names changed in the 2026 edition, so check the Foundation's own pages before quoting a name from any article, including this one. All hours figures are my practitioner estimate at roughly 20 engineers on one provider; not a measured average, not a published benchmark, and they move with your architecture. MatrixGard is not a FinOps Foundation member and holds no FinOps certification. This is a practitioner reading of public documentation; the Foundation's pages are the authority on the framework.
