Modernizing a long-lived web application

I led the rebuild of Trainerize’s legacy .NET web application as a React and TypeScript single-page application, from proposal through production beta to general availability in December 2024. The work migrated roughly three-quarters of about 200 legacy screens and widgets. It became the foundation the web team builds on today and was recognized with ABC Fitness’s Q3 2024 Growth Guru award.

Starting with a product that had years behind it

Trainerize’s web application had grown through years of iterative delivery. Its .NET-based architecture was reaching its limits for scale and pace of change. The work was therefore a modernization of an established product, with an existing collection of screens and widgets to account for.

Years of work across Trainerize’s frontend gave me context on the product before I led its modernization. I joined Trainerize in 2015, building frontend features and client integrations. By 2019, I was helping formalize React coding standards and shared UI and date/time foundations. As a senior developer, I continued building shared frontend foundations while the platform and engineering organization grew. That history provided context for the architectural work that followed.

Responsibility from scope to production

My responsibilities covered scoping the migration, setting technical direction, and driving implementation. The consequential architectural change was the redesign and rebuild as a single-page application using React and TypeScript. My delivery responsibility extended from the proposal through a production beta and general availability. The single-page application began as a foundational build for local development and matured into an application complete enough to replace the production application.

The scale of the existing application made migration scope a concrete part of the job: the delivered work covered roughly three-quarters of about 200 legacy screens and widgets. That scope describes what moved; it does not establish that every part of the previous application was replaced.

The wider engineering question was how to evolve an established product while accounting for what was already there. My approach to long-lived products is to examine what is worth keeping, what needs rethinking, and how to improve it without bringing everything to a halt. Here, the delivery path ran through a production beta before general availability.

A new foundation, with continuing ownership

The result was a single-page application in general availability in December 2024 and a foundation for the web team’s subsequent work. My responsibility continued after launch: I took ownership of SPA production behaviour and authentication, including an enterprise SSO integration for a partner.

This work brings together two parts of how I think about architecture: deciding where a frontend needs to move and doing the work needed to get it into production. The useful lesson is to consider the migration boundary and the responsibility after launch alongside the target architecture. In this project, scoping, implementation, production behaviour, and authentication were all part of my contribution.