A monolith split without a freeze week
Service boundaries drawn from real traffic and migrated behind feature flags over two quarters — with feature delivery continuing the entire time.
Where they were
A logistics SaaS had grown to 40 engineers on one Rails monolith where a deploy took 90 minutes and any failure blocked every team.
A previous rewrite attempt had been abandoned after nine months with nothing shipped.
The board wanted a plan; the engineering team wanted to stop being blamed for velocity.
What we did
01Instrumented before drawing any boxes
Six weeks of call-graph and data-access tracing showed where the real coupling was. Two of the four services the team had planned to extract turned out to share a hot table and would have made things worse.
02Extracted in dependency order, smallest first
The first extraction was deliberately boring — a service with a clean edge and low risk — to prove the pattern and build the tooling everyone would reuse.
03Dual writes, flags, and backfills
Every migration ran old and new paths in parallel with comparison logging until divergence hit zero. No cutover was ever a leap.
04Left the pattern behind, not the dependency
The client's engineers ran the final three extractions themselves using the templates and runbooks from the first two.
“The first thing they did was talk us out of two of the four services we'd already promised the board. That's when I knew we'd hired the right team.”
What it was built with
Let’s talk about yours.
Mention this case study in your note and we’ll come to the call with the specifics of how it went — including what we’d do differently.