Your Younger Self Is Still in Production

Sometimes legacy code is just your younger self still running in production.

That is a stranger feeling than inheriting someone else's mess. You are not arriving as the hero who finally understands what the previous team got wrong. You are meeting your own earlier decisions, still serving users, still holding revenue, still shaping how people work every week. Some of those decisions turn out to be surprisingly durable. Some were right only for the world in which they were made. Some survived for no deeper reason than that nobody had a strong enough reason to touch them.

We built TaxiManager years ago. It was not a failure waiting to be corrected. It worked. It had users. It made sales. For a long time it solved a concrete problem for UK taxi and private hire drivers who needed weekly income and expense structure that accountants could actually use. The old version is not the villain of this story. We are not writing the usual rewrite myth: once it was done badly, now it has been done properly.

We built a system that fitted its time. Then the world around it moved.

The product outlived its first world

Technology moved, users expected more, and the product itself needed a longer horizon. Making Tax Digital arrived. HMRC integration stopped being a distant idea and became a real next stage. Automation stopped being a nice extra and became part of how the product needed to grow. The architecture that had been enough for years started to limit what came next.

That is the interesting moment. Not the discovery that old code looks old. The moment when you have to decide what to defend and what to leave behind.

The strange thing about rebuilding your own software is that every bad decision once had a reason.

Coming back to your own system, you remember some of those reasons. You also see how many things that once looked like implementation details became part of the way users actually work. A field that existed because of an old constraint. A weekly ritual shaped around what the software made easy. A report that mattered because one accountant trusted it. You cannot simply "write it better". You have to keep the product logic that still earns trust, without copying every limitation that came with the first version.

This is harder than a clean-slate fantasy, and more honest than a rescue narrative. The first version did its job. The question is whether it can still carry the job the product now has.

What we kept, what we refused to copy

Returning to TaxiManager meant reading our own past with less romance and less contempt.

We kept the product's core: weekly driver work, structured records, accountant-ready meaning. That was never the weak part. What had to change was the foundation underneath it. The old shape could still serve yesterday's product. It could not cleanly carry MTD, HMRC, deeper automation and another decade of development without becoming a museum of patches.

So V2 was not a moral correction. It was a structural one. We built a new technical base, a new interface and a model that could grow again. We moved a working business without shutting the old world off with one brutal switch. The old version stayed available as a safety path. The new one took production, users and sales. The live product is at taximanager.co.uk. The system now has a structure on which HMRC work, automation and the next years of the product can actually be built.

Legacy is often success with a lag

People talk about legacy as if it were mostly a story of poor craft. Sometimes it is. Often it is not.

Good software does not become legacy because it was badly built. It becomes legacy because the world around it keeps moving.

A product that lasts long enough will eventually sit in a world it was not designed for. Tax rules move. Platforms move. The sales channel moves. What users expect from a phone screen moves. The integrations that once felt optional become mandatory. If the software was useless, it would already be gone. The fact that it is still there, still used, still commercially alive, is often the proof that the first build was good enough to matter.

That is a more useful way to look at TaxiManager V1. We are not disowning it. It did what it was built to do for long enough that the business around it grew into a different set of pressures. V2 is not the erasure of an embarrassing mistake. It is the next construction of a product that survived long enough to need one.

This also changes how you rebuild. If you treat the old system as a corpse, you throw away too much. If you treat it as sacred, you rebuild the prison. The useful posture is narrower: respect the product knowledge that still holds, and replace the structure that can no longer carry the next obligation.

What returning teaches

There is a particular discipline in rebuilding your own work.

You remember why a shortcut existed. You also see the cost it collected later. You notice which abstractions aged well and which ones only looked clever in the week they were written. You learn that some user behaviour is not "legacy mess". It is product truth that never got named properly in the original model. And you learn that the most expensive lie in a rewrite is the idea that the past was simply incompetent.

Younger-you was working with different constraints: different stack pressure, different market, different regulatory weather, different appetite for complexity. Judging that work only by today's requirements is a cheap form of wisdom. The real work is separating the decisions that still deserve defence from the ones that only made sense then.

TaxiManager forced that separation into the open. The weekly logic still mattered. The old ceiling did not. So we rebuilt the ceiling, moved the business across carefully, and left the product pointed at the years ahead instead of trapped inside the years behind.

We did not rebuild TaxiManager because the old version had failed. We rebuilt it because it had succeeded for long enough to outgrow the world in which it was created.