What 'Stop, Drop, and Roll Out' Looks Like in a Real Engagement

We talk about “Stop, Drop, and Roll Out” as if everyone knows what it means. Most don’t, and the marketing-page summary (“streamline your existing environment”) doesn’t communicate what we actually do. Here’s the framework walked through a real engagement — names withheld, structure intact.

The setup

A 280-person SaaS company, four years post-Series-B, asked us in for a discovery call after a near-miss security incident exposed how much of their stack nobody understood anymore. Three engineering teams, two CTOs in succession, six different “the new standard” platforms tried and partially adopted. Classic mid-stage chaos.

Engagement scope: 90 days. Goal: stop the bleeding, then build the right thing on top of what’s left.

Week 1–2: STOP

The Stop phase is about understanding what’s actually running before changing anything. We resist the urge to fix obvious problems immediately — early fixes without context create new ones.

What we did, in order:

Inventoried every running service. Production, staging, “we forgot we had that.” Output: a 47-row spreadsheet, of which 12 rows were workloads nobody on the current team could explain.
Pulled the AP system for SaaS contracts. Found 8 vendors not in the IT inventory and 3 vendors in the inventory that had been cancelled but were still being billed (vendor-side billing error; recovered).
Walked the IAM permission graph. 23 service accounts with credentials that nobody currently employed had created. Three had production write access.
Read the last 90 days of incident postmortems. Pattern: four out of seven incidents traced back to the same two integrations nobody had ownership of.

The Stop phase deliverable is always a written ledger. If we leave at the end of week 2, the ledger is itself worth what we’ve cost. That’s the bar.

Week 3–6: DROP

Now we start removing things. The discipline is don’t add anything new yet — every addition is technical debt until proven otherwise.

What got dropped:

3 cancelled-but-billed SaaS contracts (recovered $14k/year)
12 zombie services, after a week of dependency tracing proved nothing in production called them
23 orphan service accounts (rotated keys on the 3 active ones, deleted the rest)
1 entire integration platform that had been bought to replace a different integration platform, neither fully migrated to, both still running
8 dormant Salesforce permission sets (a small permissions audit, since we were already in there)

Net result by end of week 6: the surface area to reason about shrank by roughly 35%. That’s the metric the Drop phase optimizes for. Less surface, fewer footholds, faster systems.

The Drop phase looks unproductive from the outside — “you’re not building anything.” That’s the point. The post-Drop foundation is what makes the Roll Out productive instead of additive-to-chaos.

Week 7–13: ROLL OUT

Now we build. With a clear ledger and a smaller surface, the things that needed building become obvious — and they ship faster than they would have on the original mess.

What got built:

A single observability layer covering the surviving services (Cloud Run + on-prem mix). Replaced the three partial monitoring tools.
A custom MCP adapter for the agentic AI workflow the product team had been trying to scope for six months. With the dependency graph clean, the scope took 90 minutes to nail down.
A continuous SOC 2 control validation harness running on every deploy. The compliance team stopped manually assembling evidence packages.
A consolidated identity workflow — replaced 4 different SSO provider setups across the surviving services.

Each Roll Out item shipped in days-to-weeks, not the months they’d have taken on the pre-Stop foundation.

What the client got at day 90

$43k/year in immediate vendor savings
35% reduction in operational surface (their internal scoring)
One observability layer instead of three partial ones
A continuous compliance harness instead of quarterly manual evidence assembly
An MCP-mediated AI workflow shipped in production
A documented architecture diagram that matched reality for the first time in 18 months

Total cost: less than the cost of one full-time senior engineer for the year. Outcome: a foundation that the client’s own team can build on without us.

Why the order matters

The most common mistake we see in similar firms is Roll Out without Stop or Drop. New tools, new platforms, new agents — layered on top of architecture nobody fully understands. Six months later it’s the same chaos, just deeper.

Stop, Drop, Roll Out works because it inverts the order. You earn the right to build new by demonstrably reducing what’s already broken first.

What we’d do

If your stack is past the point where any one person can hold it in their head, this is the engagement that resets the foundation. 90 days, fixed scope, ledger-first.

The full Lean-First Approach runs on every engagement we take. Read the approach → · Book a discovery call →