I was not working in the legacy system itself. My role was focused on the conversion effort, building the new application in modern Angular while the existing platform continued to be developed by the main team. So from the beginning, there was an imbalance built into the work. I was trying to move the future forward as one developer, while a whole team continued adding to the past.
That changed how I approached the project. I was never trying to go back and clean up the old codebase directly. My job was to create the replacement, to build something structured enough that it could eventually take over. That meant the work was not just about rebuilding screens in a newer framework. It was about establishing a foundation that the old system had never really had.
I treated the new application like a real product from the start. I put structure around it early, with a component-driven architecture, clear separation between features and shared utilities, and strong typing throughout. I wanted each part of the system to have a defined place so the project could grow without collapsing into the same kind of sprawl that had made the original system so hard to replace.
One of the first practical problems I solved was the dependency on backend readiness. Waiting on API changes would have slowed the conversion even further, so I set up a mock API with Node and Express to let the frontend move independently. That made it possible to build out real pages, flows, and models without having to stop every time another dependency was missing or unstable. It gave the project momentum, and more importantly, it made the work predictable.
I also put a lot of effort into the development standards around the project. I set up linting, formatting, and pre-commit hooks so the codebase would stay consistent as it grew. I built out CI/CD pipelines so every pull request had to pass validation before it could be merged. Builds ran automatically. Lint checks ran automatically. Cypress tests ran automatically. Quality was built into the system itself instead of relying on memory or good intentions.
Testing became a major part of that foundation. I used Cypress for both end-to-end and component testing because I wanted changes to be safer than they had been in the older environment. Instead of waiting for issues to show up later, the goal was to catch regressions early and make the project trustworthy.
I also set up a workflow that made the project feel like something a team could actually step into. Feature branches, pull requests, automated validation, and staged environments were all part of that. Development, staging, and production each had a purpose, and changes followed a consistent path through them. I was not just building pages. I was building the conditions for a real team to work effectively in the new system.
On its own, that foundation was solid. It worked. It was predictable. It was ready.
But the environment around it never really moved in that direction. At the same time, the legacy system didn't slow down. It kept growing. New features were still being added, still expanding the surface area of something we were supposed to be replacing. That created a gap that better code or structure alone couldn't close. It was a resource problem, and more importantly, a priority problem.
I was used to working in larger teams with a defined development rhythm. Daily standups, sprint planning, retrospectives, and a shared understanding of how work moved from idea to release. Even in large, complex systems, that structure made it possible to move quickly without losing control. There was alignment, and there was momentum.
This team operated differently.
It was smaller, more isolated, and much more private in how work got done. There was not a strong or consistent agile process in place, and what did exist did not really drive the work forward. Standups felt more like status updates than coordination. Retrospectives either did not happen or did not lead to change. Planning was often reactive instead of intentional.
Work still got done, but there was very little structure behind how or why it was done that way.
I tried to push things in a different direction a few times. As project management changed, there were moments where it felt like there might be room to introduce a more structured workflow. I pushed for clearer sprint cycles, better communication, and more consistent processes around how work was planned and delivered.
But it never really stuck.
There was a strong sense of inertia in the existing team. The process they had was familiar, and it worked well enough for what they were used to. There was not much appetite to change it, especially for something that felt like overhead instead of immediate output.
That created a disconnect.
The system I was building depended on structure. It was designed for a team to step into, to move quickly, and to rely on shared patterns and predictable workflows. But the environment around it was not moving in that direction.
By the time that foundation was in place, the contrast was already obvious. The new system was structured, validated, and built to scale. But it was still only one stream of work, while the legacy system continued moving forward under the weight and momentum of a full team.
That was the tension underneath everything. And it didn't feel temporary. It felt like something that was just going to keep going.