Before I started building my own things, Pip-Boy.com, tools, all of it, I was trying to rebuild something else. I had just taken a new job after three years of solid work, expecting a fresh start.

I began working inside a legacy system. Not just old code, but years of decisions stacked on top of each other. The kind of system where nothing is completely broken, but nothing is easy either. At first, I was honestly excited. I think most developers are when they walk into something like that. You see problems and your brain immediately goes to fixing them. Clean it up, put some structure around it, make it better than it was. There's something satisfying about seeing chaos and thinking you can shape it into something solid.

And there was a lot to fix.

The frontend was AngularJS, and it had been growing for years without any real boundaries. The files were huge. Logic, styles, and side effects were all mixed together. Third-party libraries were sitting directly in the repository. Some files were massive and touched far too much. It was messy, but more than that, it was fragile. Every change felt risky. Not because anything was especially complex, but because everything was tied together in ways that were not obvious. You could change one thing and something unrelated would break somewhere else.

But the biggest issue wasn't the code.

The system was already far behind, more than a decade in some ways, and we were still actively building new features into it. At the same time, I was brought in as one developer to rewrite the entire frontend into modern Angular. So both things were happening at once. We were trying to replace the system while still actively growing it, and that tension set the tone for everything that came after.

Even then, I did not think it was doomed. Plenty of teams deal with legacy systems, and plenty of rewrites succeed. I assumed it just needed a solid foundation, and then we could build a team around it. That was the plan I focused on.

For about a year, I worked on setting everything up the right way. CI/CD, automated testing, linting and formatting, pre-commit hooks, and Cypress for both end-to-end and component testing. Everything ran locally and in the pipeline. GitHub Actions enforced that nothing could be merged unless it passed. It was not about making the project look nice. It was about making something that could actually support a team. Something predictable, something clean, something where a developer could step in and not spend their first week fighting the project itself.

From the start, I never expected to be the only one working on it for long. The idea was simple. Build the foundation first, then bring people over and start moving faster.

After about a year, that foundation was there. It was ready.

That is where things stopped lining up with what I expected.

I thought that would be the point where people started moving over from the legacy team, where real work would begin shifting into the new application, where it would start being treated as the future system. That did not happen. Instead, new features kept getting built in AngularJS. The rewrite stayed off to the side. It existed, it was solid, but it was not where the work was going.

I kept pushing for more people to join the new project, over and over. At one point, it was basically just me and a junior developer I was mentoring. We were trying to build something new while also getting him up to speed, while the rest of the team continued building in the old system. There was never a moment where things flipped. No clear decision that this was the direction moving forward. No real transition.

Without that, it did not matter how solid the foundation was.

You cannot outpace a full team adding features to the system you are trying to replace, not alone and not with two people. I said that pretty directly. We needed more people on the new system. We needed to actually commit to it. Otherwise, we were going to keep falling behind.

But it never really landed.

At the same time, expectations did not change. There was still pressure to move faster, catch up, and deliver more, but the setup to actually make that possible was never there. That gap just kept getting bigger.

That is when it started to click for me.

The problem was not just the code. It was the direction.

I did not walk into a bad project. I walked into a project that had been carrying a lot of decisions for a long time, and we were still adding more on top of it.