FinOps is one of those terms that means very different things depending on company size. For a Fortune 500, it's a 30-person practice with a CFO sponsor, a tooling budget bigger than your payroll, and quarterly steering committees. For your 30-person SaaS, it's roughly: "why is the AWS bill 27% higher than last quarter, and whose job is it to find out?" This post is for the second group.
First, the reassuring news: cloud waste is boring. The overwhelming majority of it comes from the same five patterns, at every company, at every scale. Idle compute nobody switched off. Oversized instances provisioned for a peak that never returned. Untagged resources nobody can attribute, so nobody feels responsible. Forgotten development and staging environments running around the clock for software that ships twice a month. And storage sitting on premium tiers years after anyone last read it. None of these require a FinOps Foundation certification to fix. All of them require someone to actually look.
The pattern we see most often deserves its own paragraph. A developer spins up a c5.4xlarge for a load test on Thursday. The test wraps up at 4pm Friday. The instance runs over the weekend, because turning it off is a manual step in a console nobody opens on Saturday. By Monday standup the team has burned €180 on an idle box - not through incompetence, but because the system's default is "keep billing." Multiply by every team, every weekend, every forgotten experiment, and you have a meaningful percentage of your infrastructure budget doing precisely nothing.
Why don't dashboards fix this? Because visibility was never the bottleneck - your cloud provider already has a cost explorer, and you already don't open it. A dashboard tells you what happened after the money is gone, in a place you have to remember to visit, in a format that requires twenty minutes of filtering before it says anything actionable. Between "the data exists" and "someone acted on it" sits the entire actual discipline of FinOps, and it's exactly the part a small team has no spare capacity for.
There's also a structural problem dashboards can't solve: multi-cloud fragmentation. The moment you run AWS for the product, Hetzner for batch workloads, and a stray DigitalOcean project someone started in 2024, "what do we spend" stops having a single answer. Each provider exports costs in its own format, on its own schedule, with its own idea of what a project is. Most small teams respond by tracking the big bill carefully and letting the small ones drift - which is how a €400/month leak survives for two years.
So what does FinOps actually look like for a team with no FinOps team? In our experience, four habits cover most of the value. One: a single source of truth for spend across every provider, broken down by service, project, and environment - not because dashboards fix things, but because arguments about attribution die when everyone sees the same numbers. Two: anomaly detection that's smarter than a threshold - cloud bills are naturally noisy, and a static "alert me over €X" either fires constantly or never; flagging genuine deviations from your own baseline is work for ML, not for a cron job and hope. Three: right-sizing recommendations on a cadence - a monthly list of "these twelve instances are oversized, here's the safe smaller size, here's the saving" that someone reviews in fifteen minutes. Four: budget alerts that escalate - a quiet warning to the engineer at 80%, a louder one to the team lead at 100%, because a budget nobody is accountable for is a wish.
Notice what all four have in common: they shorten the loop from insight to action. That's the entire game. Not more data - less distance between "the system noticed" and "a human decided." A small team doesn't need a FinOps practice; it needs the twenty minutes a week where cost decisions happen to be well-prepared, pre-prioritized, and in one place.
That's what we built into Sencai: spend by service, project, and environment across every connected provider; ML-flagged cost anomalies; scheduled right-sizing recommendations; budget alerts that escalate. The loop from insight to action, compressed to fit inside a standup. And the next step on the roadmap - Autopilot - is about closing that loop entirely for the boring cases: auto-stopping tagged dev resources on schedule, executing approved right-sizing during maintenance windows. The judgment stays with you; the button-pressing shouldn't have to.
If you want to know where you stand today, here's a fifteen-minute exercise: pull last month's bill from every provider you use - including the ones you'd forgotten. Sort by service. Circle everything you can't attribute to a running product feature within ten seconds. At most companies that circle is 25-35% of the total. That's not a budgeting problem. That's just entropy - and entropy is very, very fixable.