From "nobody touch billing" to shipping a new pricing model in weeks
A growing ecommerce platform had reached a point familiar to many Rails teams: the system still worked, but every meaningful change carried increasing risk or regression.
Features took longer than expected. Engineers avoided certain parts of the codebase entirely. Delivery planning became less about roadmap priority and more about which areas felt survivable to modify.
Billing was the clearest example. Leadership had effectively concluded the system was too fragile to safely evolve.
The issue wasn’t a single architectural mistake. It was years of reasonable short-term decisions accumulating into a system that had become increasingly difficult to reason about under delivery pressure.
Bringing a 100,000-line application back under control
Rather than attempt a rewrite or broad “cleanup” effort, the engagement focused on restoring safe momentum incrementally:
- clarifying architectural boundaries
- extracting business logic from high-risk areas
- improving test confidence around critical workflows
- continuously prioritising the highest-leverage constraints
Just as importantly, technical decisions were framed as business trade-offs rather than engineering ideology. In several cases, the best path forward was neither the fastest implementation nor the “purest” architecture, but an intermediate approach that balanced delivery pressure against long-term maintainability.
Over time, the engineering team scaled from two developers to six without delivery complexity scaling at the same rate.
The clearest outcome came near the end of the engagement: the company went from “don’t touch billing” to delivering a completely new pricing model in a matter of weeks.
The constraint was never developer capability. It was accumulated delivery risk — and the absence of sustained technical stewardship focused on reducing it.