Ship first, modernize later

I started with Vue because I needed something to run.

Not because I had a five-year architecture plan. The tools grew anyway — year after year, problem after problem from the business. What did not grow at the same speed was the foundation underneath. The frameworks stayed where they were. The features did not.

For a long time that felt fine. People used what I built. That was the point. Upgrading everything just to say I was “modern” would have meant stopping delivery. I am a managing director first. The software has to earn its keep.

I also knew the stack was getting old. I could read the warnings. I could write plans for what a proper modernization might look like. Writing the plan was easier than finding the months to execute a full rewrite while the old system still had to work every day.

So I did not rip everything out.

I started a successor next to it. Same business, cleaner foundations, deliberate redesign — not a one-to-one copy of every screen. The old tools keep running. The new ones take over piece by piece. That is slower to brag about. It matches how the company actually works.

The hard part is not picking the new stack. The hard part is admitting that skill can run ahead of bandwidth. I can see what “better” looks like and still ship on what is already there — until there is enough room to build the next layer for real.

If you build software inside your own business, you will hit this. Shipping on something outdated is not always laziness. Sometimes it is the price of staying useful. And starting fresh beside the old system is not giving up. It is refusing to burn the house down so the kitchen can get a new sink.