By the time the engagement started, the platform had outgrown the architecture it was built on. Revenue ran in the eight figures. The codebase ran in stitches. Every new market the business entered surfaced another structural limit, and the operating cost of working around those limits was beginning to dominate margin.
The choice was the one every operator at this scale eventually faces. Patch and pay forever, or rebuild and lose six months. Both options were wrong.
Rebuilding in production
We took a third option. Rebuild in production. No freeze, no migration weekend, no parallel cutover months in the future. The new system stood up next to the old one, took progressively more traffic, and the old system was decommissioned in pieces. Operating revenue never dropped.
This is not a heroic story about engineering speed. It is a story about engineering structure. The migration plan was designed around the shape of the cash flow, not the shape of the codebase. Every decision about ordering followed the rule that the next revenue-generating week had to survive the next architectural change.
A rebuild that requires the company to stop earning is not a rebuild. It is a bet that the market waits. Markets do not wait.
Three weeks of decisions, six months of work
The hardest part of the engagement was the first three weeks. That was when the structure of the rebuild was decided. After that, the work was hard but ordinary. Engineering, sequencing, deployment, validation.
Most rebuilds at this scale fail because the operator wants to begin with code. The code is the easy part. The structure of the migration is the work. The rule we use is simple. If the rebuild plan does not survive an open laptop on a Sunday, it will not survive a customer issue on a Tuesday.
What the platform looks like now
The new architecture is structurally simpler. Fewer services, cleaner boundaries, faster deploys. The cost of running it is roughly half. The cost of changing it is roughly a quarter. The cost of entering a new market is now a configuration problem, not an engineering problem.
That last point is the one that matters. The point of the rebuild was never the architecture. It was the economics of expansion. Once those economics were unblocked, the next twelve months looked very different.
What we underwrite
We engage on platform rebuilds where the system is already producing revenue but is structurally blocking the next phase of growth. The engagement is not advisory. We commit, we operate, we ship. The economics of the rebuild are designed around the economics of the business, not the elegance of the system.
This is a narrow lane. It is not for everyone. It is for the operator who knows the rebuild has to happen, knows it can't happen with a freeze, and needs the structural support to do it the way it should be done.