React 16, Node 12, no TypeScript, a single CSS file with 1,500 lines... and of course no functional specs.
That's what our subscription application for TV devices looked like. The majority of the team decided it would be best to start over from scratch.
An application with constraints
Our application allows people to subscribe directly to services on their televisions, such as packages giving access to applications, without needing another device.
The main challenge with this type of device comes from technical constraints that are stricter than on the traditional web. Built-in browsers cannot be updated, which prevents the use of certain recent JavaScript, CSS, or HTML features.
So we are stuck with so-called “old” technologies more out of necessity than choice.
The code reflected these constraints:
- React 16, therefore in the React class
- No TypeScript
- No React Router
- CSS styling
For a developer accustomed to modern stacks, this was not at all appealing.
Restarting the project: challenges and constraints
When a new Product Owner took over the project, his first observation was that the application was “too outdated.”
The obvious solution, which was immediately proposed, was to start a new project. It seems easier to start over than to repair what already exists.
But there was a catch: despite numerous UX and architectural proposal meetings, we kept coming back to the same technical constraints.
What's more, the new project would have the same constraints as the old one, but with:
- Several months of development
- A complete qualification phase
- Integration of the company's various teams (sales, support, etc.)
- A risk of functional regression
- Zero value delivered for the company during this time
One question kept running through my mind: What if we improved what we already had?
The more I compared the models for the new project with what we already had, the less I saw a revolution...
The real question that no one was asking at that moment was:
“Have we really tried to improve what we already have?”
Unfortunately, the answer was no. We had always focused on features, never on continuous improvement of the product.
I pushed this idea, and my superiors followed me.
The strategy: incremental improvement
Phase 1: Design and UX (1 sprint)
We started with what is visible, for example:
- Redesign of the background image
- Redesign of the buttons
- Improvement of UX positioning
The result was already visible when it was presented to the sales team.
Phase 2: Continuous technical improvement (2-3 sprints)
We tackled technical debt in small steps:
Backend:
- Migration from Node 12 to Node 22 (progressive, in several stages)
- Refactoring of endpoints
- Improvement of code structure
Frontend:
- Creation of reusable components
- Improvement of folder structure
Quality:
- Systematic processing of the anomaly backlog
- Correction of bugs that had been around for years
- Improvement of stability
Phase 3: Measurable results
After several months of this approach:
Technical
- Node 12 → 22: successful migration without regression
- Reusable components created
- Technical documentation
Quality
- Bug backlog: reduced by approximately half
- Pilot site testing: 0 anomalies reported
Business
- Positive user feedback
- Sales staff satisfied to see a product improving
Team
- Motivation maintained (continuous delivery of value)
- Increased skills in refactoring
- Pride in seeing the product improve
Lessons learned
1. New things are always more appealing, but they come at a cost
Starting from scratch gives the illusion of building on a solid foundation. In reality:
- We always underestimate the time required
- We lose the business knowledge hidden in the code
- We often repeat the same mistakes
- We deliver no value for months
2. Legacy code isn't always bad
Our application was described as “legacy,” which should not be confused with “obsolete”:
- It runs on React 16 - This isn't the most recent version, but it's still functional
- It worked and had satisfied users
- It contained proven business logic
- It was stable in production
The real problem was that we never took the time to continuously improve the existing code; we just kept adding features.
3. Technical constraints do not magically disappear
Our main limitation (devices) still existed. Rewriting would not have changed that.
Sometimes the best option is to optimize according to constraints rather than believe in a world without constraints.
Conclusion: Think before starting from scratch
Yes, our application still does not meet the criteria of the latest recommendations for modern JS stacks.
Yes, there is still room for improvement.
But today it is:
- More maintainable
- More user-friendly
- More reliable
And above all: we have delivered concrete improvements at the end of each sprint.
Sometimes, technical debt isn't in the code, but in the time we never devoted to it.
Cover image generated using AI
Top comments (0)