Case Study from a Retail SaaS Organization - FinOps

This post is not about theoretical FinOps. It reflects how we designed, rolled out, and operationalized FinOps for a retail-focused SaaS company running multiple products on Azure. The goal was never to chase immediate savings. The goal was to build cost confidence, predictability, and decision-making discipline across engineering, finance, and product teams.

The environment was complex but common: multiple subscriptions, multiple business units, independently evolving SaaS products, heavy R&D usage, and retail-driven seasonality. Costs were growing, but the bigger issue was that no one fully trusted the numbers—or knew how to act on them.

Starting with the Right Conversations, Not Tools

We began with conversations, not dashboards.

With the finance team, we focused on understanding:

• The current Azure billing model and invoice structure

• Existing benefits in use (Azure Hybrid Benefit, dev/test pricing, EA discounts)

• How budgets, accruals, and forecasts were currently built

• Where finance lacked predictability or confidence

With engineering and platform teams, we discussed:

• Workload criticality and stability

• Scale patterns and seasonal spikes

• Environment sprawl and subscription boundaries

• Known inefficiencies and technical debt

We did not negotiate with Microsoft directly, but we actively supported finance by providing data-driven inputs—usage trends, commitment readiness, and rate optimization opportunities—so negotiations were informed by real consumption patterns, not assumptions.

Defining Ownership: FinOps as a Shared Operating Model

FinOps was intentionally positioned as cross-functional, not centralized.

Responsibilities were clearly defined:

• Engineering owned workload efficiency, right-sizing, and architecture choices

• Finance owned budgets, forecasting, rate strategy, and commitments

• Platform / Cloud Ops owned guardrails, policy enforcement, and automation

• Product owners owned cost versus value trade-offs

A small FinOps core group acted as facilitators, not gatekeepers. Their role was to provide visibility, context, and options—not approvals. This was critical in building trust and avoiding friction.

Visualization and Cost Transparency Before Optimization

Before optimizing anything, we focused on visualization and data trust.

We built:

• Daily and weekly cost views instead of monthly snapshots

• Subscription-level and product-level breakdowns

• Trend-based views showing how costs evolved over time

• Environment-aware views separating prod, non-prod, and R&D

These views were shared during regular sync-up calls with engineering, finance, and product teams. The focus was not “why is this expensive?” but “what changed, and was it intentional?”

Visualization became the foundation for every FinOps discussion that followed.

Tagging as a Real-Time Control Mechanism

Tagging was treated as an operational control, not a reporting clean-up task.

We enforced a minimal, mandatory tag set:

• BusinessUnit

• Product

• Environment

• Owner

Tags were enforced at deployment time using policy. No retroactive fixes, no manual clean-ups. Teams understood that tagging was how they protected their budgets and enabled accurate chargeback—not a finance requirement imposed on them.

Workload Optimization: Fixing Usage Before Rates

We deliberately started with workload optimization before touching rate optimization.

This included:

• Right-sizing VMs and databases based on utilization

• Reviewing autoscaling behavior and scaling granularity

• Identifying idle, orphaned, or over-provisioned resources

• Applying non-production shutdown schedules

• Aligning storage tiers and lifecycle policies with access patterns

This phase reduced noise in the data and stabilized usage, which was essential before making any long-term financial commitments.

Rate Optimization: Timing Matters

Only after usage stabilized did we move into rate optimization discussions.

We reviewed:

• Where Azure Hybrid Benefit was applicable but underutilized

• Whether dev/test pricing was consistently applied

• Which workloads were eligible for savings plans versus reservations

• Regional constraints and SKU limitations for reservations

There was pressure to move fast and “lock in savings,” but we pushed back with context:

• Savings plans are commitment-based and irreversible

• Reservations are region- and SKU-specific

• Committing before understanding workload behavior introduces risk

We used historical usage trends, seasonality data, and forecast models to guide decisions—always emphasizing commit readiness over theoretical savings.

Forecasting as a Continuous Activity

Forecasting was not treated as a quarterly finance task.

We worked with finance to:

• Align forecasts with engineering release cycles

• Incorporate seasonality and expected scale events

• Separate baseline run-rate from growth-driven spend

• Validate forecasts during regular sync-ups

This made forecasts living documents, adjusted as workloads and priorities evolved.

Chargeback, Showback, and Product Accountability

With tagging, visualization, and forecasting in place, chargeback became practical.

We introduced showback first, allowing teams to understand their spend trends without immediate financial pressure. Over time, chargeback was introduced where maturity allowed.

Product owners became active participants in cost discussions, weighing spend against business impact rather than reacting to invoices.

Cadence: Making FinOps Operational

FinOps only worked because it had a rhythm:

• Weekly or bi-weekly cost syncs with engineering

• Monthly forecasting and budget alignment with finance

• Periodic commitment and rate optimization reviews

• Ongoing dashboard and alert refinement

These were working sessions, not status meetings. Data was presented visually, trends were discussed openly, and decisions were documented.

Duration, Handover, and Sustainability

The engagement ran for several months, from initial discovery through stabilization and handover.

By the end:

• Cost visibility was embedded into daily operations

• Optimization was continuous, not reactive

• Commitments were intentional and data-backed

• Internal teams owned dashboards, policies, and review cadence

FinOps was no longer a project—it became part of how the organization operated in the cloud.

This experience reinforced a core FinOps principle: optimization is a sequence, not a shortcut. Usage, rate, and commitment optimization must happen in the right order, supported by visibility, forecasting, and shared ownership.

The result was not just reduced waste, but increased confidence—across engineering, finance, and leadership—that cloud costs were understood, intentional, and aligned with business value.

If anyone reading this has implemented FinOps in a similar multi-product SaaS environment, I’d love to hear your experience. What worked well for you, and where did you face resistance?