Not by being smarter. By being ruthless about scope, aggressive about leverage, and unapologetic about deleting code. A case study in subtraction.
We want to be careful with this story because it reads, at first, like a flex. It is not. The client had a forty-person platform team that was doing good work under impossible conditions. We replaced the system they had built, not the people. Most of those engineers moved to higher-leverage work inside the company. Some of them are who we hire from now.
But the system did get replaced, and by two of us, in fourteen weeks. It is worth walking through how, because the answer is not "we are smarter." The answer is "we had permission to delete things."
The subtraction principle
The old platform had grown by accretion. Every team that needed something added a service. Every incident that happened added a guardrail. Every compliance review added a layer. By the time we arrived, the platform had forty-three services, eleven of which were doing nearly the same thing as another one, and six of which had no living owner.
Our first two weeks were not writing code. They were reading code, and reading incident history, and asking a single question: what would break if this service went away? The answer, for about a third of them, was "nothing" or "something nobody would miss."
"Not by being smarter. By being ruthless about scope, aggressive about leverage, and unapologetic about deleting code."
Leverage as a design input
The second move was choosing a platform where leverage was absurd. We consolidated thirteen data pipelines into one streaming system, three queue implementations into one, and five config services into a single file checked into version control. Every consolidation was a political fight. None of them was technically hard.
The aggregate effect was that the new system had roughly one-tenth the surface area of the old one. Two engineers can hold a one-tenth system in their heads. Forty engineers cannot hold the original system in theirs, collectively. That is the entire secret.
What we did not do
We did not write a new framework. We did not build a platform abstraction layer. We did not introduce a new language. Every one of those moves would have added a thing that later needed maintaining, and the whole engagement was predicated on things needing less maintenance, not more.
The story we want to tell about this engagement is not that two people replaced forty. It is that the platform a business needs is almost always smaller than the platform it currently has, and that the single biggest lever in infrastructure work is the delete key. We use it often. Clients almost always thank us.