AI and the Economics of Legacy Software

A few weeks ago, I started thinking about a software project that I had almost completely forgotten.

In 2013, Juanjo Meroño and I built LooWID, an open source video conferencing platform based on WebRTC. Some time later, Edu Rey joined us to help with the UI, giving the project an important qualitative leap in its user experience and making the product feel much more complete. We developed it for several years, adapting it to the rapidly changing browser and WebRTC ecosystem, until around 2018–2019 we eventually stopped maintaining it.The code remained public. The product remained there. But the technology around it moved on.

Years later, I wondered what would happen if we tried to bring it back—not by trying to make the old application run again, but by asking AI to help us rebuild the product.

The original project is still available on GitHub, and the result of the experiment is LooWID Remastered.

From legacy code to a working product

I used OpenCode as the main development agent. I gave it the URL of the old project, asked it to understand the application and to plan its modernisation using current technologies.

The transformation was substantial: the old AngularJS client became React and Vite, the backend moved to a current Express version, MongoDB was updated, and the old WebRTC implementation was reworked around today's browser capabilities.

What surprised me was how quickly the first usable version appeared. With only a couple of high-level prompts, we had most of the core experience working: entering a room, seeing and communicating with other participants, enabling and muting audio and video, screen sharing and chat.

It was far from finished, but it was recognisably LooWID.

That was the first lesson: AI can dramatically reduce the initial cost of recovering an abandoned software product.

Legacy is more than code

But the most interesting part of the experiment was not the technology.

A legacy product contains something that an AI cannot simply recreate from its source code: years of real-world experience.

People have used the software. They have developed workflows around it, discovered shortcuts, complained about things they do not understand, stopped using features that do not provide value and found ways around limitations that the original developers never anticipated.

That knowledge is extremely valuable.

When modernising a legacy system, we should therefore ask more than "How do we migrate this?" We should ask: What do people actually use? How do they use it, and why? Where do they perceive value? What frustrates them? What do they find unnecessarily complicated? What do they miss? Which parts generate incidents, support requests or disproportionate effort whenever somebody wants to change them?

The source code can tell an AI a great deal about how the system works. It cannot tell it everything about why the system matters.

The experience around the legacy product is part of the product.

That is what we should take with us into the new version.

Don't migrate everything

This also creates an opportunity to simplify.

Software accumulates layers. During development, it is often easier to add another workaround than to redesign an existing solution. Over several years, these workarounds become part of the architecture and, eventually, part of the user experience.

A rebuild gives us the opportunity to question them. Can the same capability be provided more simply? Is this feature still valuable? Does the user really need all these steps? Are we preserving something because it provides value, or simply because it was already there?

During the LooWID experiment, I deliberately left out some accessory features that no longer seemed worth carrying forward.

The objective was not to reproduce the old product.

It was to preserve its value while removing its accumulated complexity.

Screen capture from new version of Loowid

The 80/20 effect

Another clear impression from the experiment was that the classic 80/20 effect seems to appear here too. This is not a measured ratio, but the first 80% of the result came surprisingly quickly. The remaining 20%—permissions, specific workflows, edge cases and detailed behaviour—required most of the iteration.

The more specific the desired behaviour, the more important it becomes to think before prompting. Complex requirements need clear definitions and edge cases. Otherwise, each new interaction can modify something that was already working.

This led us to work in iterations: define a capability, explain the desired behaviour at a high level, implement it, test it, refine it and close the iteration before moving to the next one.

And every completed iteration became a proper Git checkpoint.

That last point is important. I would not rely on an AI agent's history as a substitute for version control. When changes happen this quickly, having known-good commits and the ability to return to them becomes even more important.

When building becomes too easy

There is also a new temptation.

At one point, I started exploring direct streaming to YouTube or Twitch. It seemed like an obvious extension: we already had video, and AI could build the feature.

It quickly became clear that it was a much bigger problem. Media conversion, RTP, additional components, browser compatibility and integration with external platforms introduced significant complexity.

So I stopped, put it on the backlog and returned to the previous stable version.

That was another useful lesson: when software becomes cheap to build, prioritisation becomes more important, not less.

We should build a clean, modular foundation that can evolve, but we should not spend our time building every spectacular feature we can imagine. Otherwise, we risk replacing old technical debt with new AI-generated feature debt.

What changes with AI?

The interesting thing about this experiment is that the AI did not make legacy disappear.

It changed the economics of doing something about it.

An old application can now be explored, understood, simplified and partially rebuilt at a cost that would previously have made the exercise difficult to justify.

But the most valuable thing in that legacy may not be the code.

It is the experience.

Years of real users, real workflows, real problems, real workarounds and real value are embedded around the software. AI can help us understand and rebuild the technology, but it cannot replace that accumulated experience.

That is what we should preserve.

This connects with the previous articles in this series: AI can help us make prototypes realistic enough to discover future value, recover time from operational work, and now revisit software whose technology has become obsolete.

The code may be ten years old. 

The experience is not.