What FinOps Maturity Actually Means
FinOps maturity is the degree to which an organization has aligned its cloud spending decisions with engineering and business outcomes. A mature FinOps practice does not mean you spend less — it means every dollar spent is a deliberate decision made by the right people with the right information at the right time.
The FinOps Foundation defines three maturity stages: Crawl, Walk, and Run. Most published guidance on these stages targets enterprises with dedicated FinOps teams, centralized tooling, and established chargeback models. At 50-500 person companies, the constraints are different: one or two platform engineers own this alongside other responsibilities, procurement cycles are short, and the cost baseline shifts every quarter as the company grows.
This post describes what each stage looks like when you are building a FinOps practice from scratch at a mid-market engineering organization.
Why Enterprise FinOps Frameworks Do Not Map to Mid-Market
The dominant FinOps frameworks assume a dedicated FinOps team of 3-10 people, established tagging governance enforced at the billing level, a chargeback model that individual business units accept, and tooling budgets of $50,000-$200,000 per year.
At a 150-person SaaS company running $80,000 per month in AWS spend, none of these assumptions hold. You have one senior platform engineer who also owns Kubernetes cluster management, CI/CD infrastructure, and incident response. Tooling budget is whatever you can justify to a CFO who still views cloud cost optimization as an infrastructure problem rather than a business metric.
The result: enterprise FinOps content either recommends tooling you cannot afford or processes that require headcount you do not have. The framework below was built from engagements with companies spending $50,000-$300,000 per month on cloud — organizations where CloudKeeper and Flexera are overkill and spreadsheet-based cost tracking has stopped working.
The Three-Stage Mid-Market FinOps Model
Stage 1: Crawl — Visibility Without Paralysis
What it is: At Stage 1, the goal is complete, accurate cost attribution. Before you can optimize, you need to know what you are spending and why.
What it is not: Stage 1 is not cost cutting. Premature optimization based on incomplete visibility is how teams create availability incidents. The output of Crawl is knowledge, not savings.
Outputs at Stage 1 completion: - Every cloud resource tagged with environment, team or service, and cost center - Monthly cost report by service and team distributed to engineering leads - Top three cost drivers identified (usually compute, data transfer, and storage) - Cost anomaly alert configured with a threshold appropriate to your spend baseline
Common failure modes: - Tagging retrospectively — teams tag new resources but ignore existing ones, making reports untrustworthy for the first three months - Using native cloud cost tools without customization, which surfaces data without actionable insight - Skipping anomaly detection until after a surprise bill
How to know you have completed Stage 1: You can answer "who is responsible for the $12,000 increase in our compute costs last month?" within 30 minutes using your own tooling.
Stage 2: Walk — Accountability Without Bureaucracy
What it is: Stage 2 shifts cloud spending from a platform engineering problem to a shared engineering responsibility. Individual teams see their spend and own their optimization decisions.
What it is not: Stage 2 is not a chargeback model. At mid-market, inter-team chargebacks create friction without material benefit. Showback — making costs visible without actual budget transfer — is sufficient and far less contentious.
Outputs at Stage 2 completion: - Per-team cost dashboards in Grafana or native tooling - Cost-per-deployment tracking integrated into CI/CD - Right-sizing recommendations reviewed quarterly - Reserved Instance or Savings Plan coverage between 60-75% of baseline compute
Common failure modes: - Engineering leads ignoring dashboards because there are no consequences — showback only works if leadership references cost data in planning conversations - Over-committing on Reserved Instances before establishing stable baselines — 12-month RIs on compute that later gets sunset are pure waste - Attempting to automate right-sizing before you have 90 days of stable utilization data
How to know you have completed Stage 2: Engineering leads reference cloud cost data in planning discussions without being prompted. Reserved Instance or Savings Plan coverage is above 65%.
Stage 3: Run — Optimization as Engineering Culture
What it is: Stage 3 embeds cost efficiency into how the team designs systems, not as an afterthought. Architecture decisions include a cost estimate. New services have cost-per-unit metrics defined before launch.
What it is not: Stage 3 is not a final state. Cloud providers change pricing, workloads evolve, and what was optimal at $100k per month may be wrong at $400k per month.
Outputs at Stage 3 completion: - Cost estimates in architecture decision records before implementation begins - Cost-per-unit metrics for key business functions: cost per active user per month, cost per API call - Quarterly FinOps reviews with VP-level attendance - 15-25% reduction in cloud spend per unit of business metric year-over-year
Common failure modes: - Treating Stage 3 as final — teams that stop iterating fall back to Stage 2 behaviors within 12 months as workloads change - Optimizing for unit cost at the expense of engineering velocity — a 10% cost reduction that costs 40 hours of engineering time per quarter is a poor trade at most company stages
Self-Assessment: Which Stage Are You At?
Answer these five questions:
- Can you attribute 90% of your cloud spend to a specific team or service within 30 minutes?
- Do engineering leads see their team's cloud costs weekly, without requesting it?
- Is your Reserved Instance or Savings Plan coverage above 65% of baseline compute?
- Are cost estimates a standard part of architecture decision records?
- Do you have cost-per-unit metrics for your core product functions?
If you answered no to questions 1 or 2, you are at Stage 1. If you answered yes to 1 and 2 but no to 3 or 4, you are at Stage 2. Five yes answers puts you at or approaching Stage 3.
Implementation Sequencing
Days 1-90: Stage 1 Completion
Enforce tagging at the account level using AWS Service Control Policies, Azure Policy, or GCP Organization Policies. Do not rely on team compliance alone — enforce it at the infrastructure layer.
Configure cost anomaly detection with a threshold of 20% week-over-week increase. Set the alert recipient to both the platform team and the engineering manager of the responsible team.
Run your first cost attribution report manually. Export from Cost Explorer or Azure Cost Management filtered by tag. Distribute it to engineering leads with an explanation of the top three cost drivers.
Days 90-180: Stage 2 Build
Once tagging coverage exceeds 90%, move to automated per-team dashboards. Grafana with AWS CloudWatch or Azure Monitor as the datasource works for most teams at this scale. The goal is a dashboard engineering leads can check weekly without platform team involvement.
Analyze your Reserved Instance opportunity. Review the last 90 days of compute usage. Identify instance types with consistent utilization above 80%. Purchase 1-year RIs for those — not 3-year unless the workload is foundational infrastructure.
Introduce cost-per-deployment tracking. A GitHub Actions step that queries Cost Explorer after each deployment and logs the projected monthly cost change is a 4-hour implementation with compounding value.
Days 180-365: Stage 3 Foundations
Require a cost estimate in new service ADRs before implementation begins. Order-of-magnitude precision is sufficient: under $1,000 per month, $1,000-$10,000, or above $10,000. The goal is to surface the conversation, not produce a precise forecast.
Define cost-per-unit metrics for two or three core product functions. For a SaaS product, this is typically cost per active user per month and cost per API call for your highest-volume endpoints.
Schedule a quarterly FinOps review at VP level. Standard agenda: current spend versus plan, top three variances with explanations, and one optimization initiative for the next quarter.
Where This Framework Breaks
This model assumes cloud spend is your primary infrastructure cost center. If you are hybrid or on-premises dominant, Stage 1 tagging governance is significantly more complex.
It also assumes engineering leadership is willing to own cost accountability. We have seen companies remain at the Stage 1 to Stage 2 boundary for 12 or more months because leadership treated cloud cost as purely a platform engineering problem. No framework resolves that organizational issue.
This model also targets AWS, Azure, and GCP. If your primary spend is on Snowflake, Databricks, or significant SaaS tooling, the attribution and optimization approaches differ substantially, though the principles apply.
Frequently Asked Questions
What does FinOps maturity mean for a 100-person SaaS company? For a 100-person company, FinOps maturity means complete cost attribution by team, weekly cost visibility for engineering leads, and Reserved Instance or Savings Plan coverage above 65% of baseline compute. Full Stage 3 optimization typically does not justify the investment until you are spending above $150,000 per month.
How long does it take to move from Stage 1 to Stage 3? Most mid-market teams we work with take 9-18 months to reach Stage 2, and another 6-12 months to establish Stage 3 behaviors. The primary accelerator is leadership that treats cost as a product metric. The primary decelerator is high engineering team turnover, which resets tagging governance repeatedly.
Do we need a dedicated FinOps tool at $80,000 per month in cloud spend? No. At under $100,000 per month, native cloud tools plus a Grafana dashboard are sufficient. Between $100,000-$500,000 per month, a lightweight platform like Vantage adds meaningful value. CloudKeeper and Flexera are designed for enterprises spending above $1,000,000 per month.
What is the typical ROI of moving from Stage 1 to Stage 2? In our engagements with 50-300 person companies, moving from Stage 1 to Stage 2 typically yields 20-35% reduction in cloud spend through right-sizing and Reserved Instance coverage. Stage 3 adds another 10-20% through architectural optimization, with more variable returns depending on workload type.
Should we start with Reserved Instances or Savings Plans? For most AWS workloads, Compute Savings Plans offer more flexibility than instance-specific Reserved Instances. They cover EC2, Lambda, and Fargate and allow instance type changes without losing the discount. Start with 1-year Compute Savings Plans at 60-65% of your stable baseline compute spend.
If you are working through a FinOps maturity assessment and want a second opinion on where you are and what to prioritize, we offer a free 60-minute FinOps review for mid-market engineering teams.
