How I Found $2M in a Cloud Bill (Without Breaking the Product)

When you get acquired, everything goes under a microscope.

Not the cute microscope. The finance microscope.

The kind where someone you've never met asks (politely) why you're spending a small nation's GDP on "data processing," and then follows up with: "Can you be at breakeven by January?"

At Heap, post-acquisition, that microscope landed squarely on infrastructure. And the target wasn't vague:

Target: a multi‑million reduction in Heap infra by Jan 2025.

No product breakage. No "we'll just slow down shipping." No "let's degrade the experience but call it a tradeoff." Just: find the money, keep the product standing.

The Scrutiny Lens (a.k.a. "Show me the receipt")

This was not a "let's trim a few EC2 instances" situation. This was: we are going to learn what we're paying for, why we're paying for it, and what happens if we stop.

I opened the bill and had the classic moment: hundreds of line items, half of them sounding like Pokémon evolutions of services we once loved.

This is where leaders get hit by the translation tax. Finance speaks in margins. Engineering speaks in blast radius. Leadership speaks in timelines. Everyone is technically correct, and nobody is talking to each other.

So I built a strategy doc that spoke all three languages at once—and (this part matters) gave the team a "Magic Click" moment: Ohhh, we're not "cutting costs," we're deleting incidental complexity that's been quietly billing us rent.

Necessary vs. Incidental Complexity (The Terrain)

Here's the thing about post-acquisition cost pressure: it's not just numbers. It's identity.

Teams hear "cut spend" and translate it (incorrectly, but emotionally accurately) into:

• "Your work doesn't matter."
• "Your system is a mistake."
• "We're going to break the product to make finance happy."

So I used a framework I trust under stress: Necessary vs. Incidental Complexity.

• Necessary complexity is the stuff that creates customer value and keeps the product real.
• Incidental complexity is the stuff that exists because history happened, org charts shifted, and nobody had a safe moment to delete anything.

That distinction was how we defended product value while still being ruthless about waste. It gave engineering a principled "yes/no" filter. It gave leadership a narrative. It gave finance a path to savings that wasn't just "turn things off and pray."

The Efficiency Seesaw: Two Tracks, One Goal (The Map)

Here's the core decision that made the whole thing executable.

We ran a dual-track strategy—and this was straight out of the FY24 plan:

• High Confidence: shipable, measurable changes with a sane rollback plan. These were about buying time and runway.
• Big Bets: bigger swings with bigger unknowns. These were about changing the long-term cost structure, not just "making the month look better."

Because if you only do "safe" wins, you'll make progress and still miss the number. And if you only do "big bets," you'll run out of time and end up with… vibes.

This is the seesaw: certainty vs. ambition. You need both. You just can't pretend they're the same.

High Confidence Projects

These were the projects where we had enough signal to commit, plan, and deliver. They weren't glamorous. They were effective.

Category	What it covered	Immediate Impact	Annualized Savings
Cloud Economics	Consolidating accounts, unifying billing, flexible savings	Significant	Material
Systems Infrastructure	Decommissioning legacy systems and "mystery boxes"	Material	High
Tooling & Observability	Reducing overlap without going blind	Gradual	Transformative

Cloud Cost Alignment (the Heavyweight Champion)

Let me say the quiet part out loud: the biggest win was not a heroic technical rewrite.

It was leadership + negotiation.

This was the heavyweight champion of the savings goal: high impact, low lift, and almost zero developer burnout—because it required zero engineering tickets and a lot of uncomfortable cross-functional conversations.

The post-acquisition leverage: "One Company"

Post-acquisition, we had a new superpower: we could act like one company with the cloud provider.

That meant we could do the grown-up cloud economics playbook:

• consolidate accounts,
• unify billing,
• and flip "unused reservations" into something more flexible.

The smart play

No Jira tickets. No migrations. No "everyone pause feature work."

Just a very intentional sequence:

1. get alignment internally ("we are one company now, act like it"),
2. negotiate hard with the provider,
3. consolidate, simplify, and stop paying for commitments we weren't using.

The lesson

"Oh. We can stop bleeding money without asking engineers to suffer."

That's Efficiency Sequencing at its best: find the massive win that costs the least in human energy.

The Secret Sauce (The "How," not the "What")

It wasn't about having a perfect map. It was about navigating a changing landscape with contingency plans.

The Q1 sprint: go all-in early

We basically went all in during Q1. Not because Q1 is magical—because it's when you still have time to correct course.

Weekly COGS reviews: the habit loop

Two things mattered more than any single project name:

1. Weekly COGS reviews — Not "once a quarter when someone panics." Weekly. Same cadence as product health. Same seriousness as reliability.
2. Make it normal — The goal wasn't to create a heroic cost task force. It was to make cost-awareness part of the system.

The ace in the hole: reserve projects

We also kept reserve projects up our sleeve. Projects that were scoped, understood, and ready to go. The point wasn't to be dramatic. The point was to be ready.

The Deletion Party

Cutting infra cost is 40% analysis and 60% social engineering.

Because the real blocker is rarely "we don't know what this service does." It's: someone is afraid to delete it.

So we made it a thing. A ritual. A checklist. A rollback plan. A place to point your anxiety.

That's how you turn optimization from a punishment into a team sport.

Low Confidence / Big Bets

The strategy had ambitious bets. That was intentional. And here's the part that still hurts to say out loud: most of the Big Bets didn't pan out.

Not because the ideas were dumb. Because reality is undefeated: timelines shift, dependencies fight back, product constraints show up late.

So we did the most strategic thing you can do mid-flight: We stopped investing in what wasn't working.

Personal lesson: Strategy isn't about being right 100% of the time; it's about being prepared when 50% of it breaks.

"Breakup to Breakeven" (The Pivot)

The plan was simple on paper: find the unprofitable outlier accounts and "break up" our way back to margin health.

And then we met reality. We liked the revenue too much to walk away.

So we pivoted to something better than exits: prevention.

The solution: the GTM Shield

Instead of guessing whether an account would be healthy, we built the GTM Shield: a COGS forecasting tool that let us stop doing math via vibes.

Education over exits

We used it to educate the Go‑To‑Market teams so they could spot "bad math" before the contract was signed.

"Oh. We don't need to kick customers out. We need to stop selling deals that are structurally underwater."

The Result (and the permanent change)

We hit $2M+ in annualized savings—and the more important part is that we didn't treat it like a one-time cleanse.

The culture shift was the win:

• Engineers started asking "what does this cost?" as a default question, not a special occasion.
• Leadership got a model they could trust: what's immediate runway vs. what's long-term COGS reduction.
• Finance stopped feeling like the villain in the story.

The part people miss: this is leadership work

The savings weren't just "smart technical choices." They were a product of:

• choosing the right sequencing (Immediate Impact runway first, then Annualized Savings big bets),
• translating across finance/eng/leadership without losing the plot,
• building operational muscle (weekly COGS reviews) instead of relying on heroics,
• and giving people psychological safety to delete things.

Because the cloud bill is never just a cloud bill. It's a mirror of how decisions get made, how long systems live past their purpose, and how expensive "we'll deal with it later" becomes.

---

Optimization isn't about being cheap. It's about being intentional. What are you paying for that doesn't matter?