A learning platform used by 1.8M learners

Context

The platform served learners for one of the world's largest education publishers. Publishing schedules do not move: a release date tied to a school term is a date, not a target, and the work had to absorb that constraint rather than negotiate with it.

Internally the project carried a different problem. It was treated as a non-profitable line of work — the CEO included — which is the kind of judgement that becomes self-fulfilling: an old codebase nobody invests in gets slower to change, which confirms that it was not worth investing in.

Scale

What I decided and built

• ›Joined as a frontend developer and grew into the technical lead — on React and TypeScript against a Ruby on Rails and PostgreSQL backend.
• ›Ran a large refactoring of the legacy system rather than working around it, on the argument that the cost of changing it was the actual product problem.
• ›Introduced automated testing, so that a platform on a fixed release schedule could be changed without the release becoming the test.
• ›Modernised the library stack the platform was built on.
• ›Took the customer relationship directly — the client was in every Scrum call, which turned requirements into a conversation instead of a handover.
• ›Proposed a long list of improvements and implemented a large share of them myself, rather than leaving them as a backlog nobody owned.
• ›Led the technical interviews for hiring onto the project.
• ›Took the case to the product owner, PM and CTO that the platform was over-featured, and got the inherited features nobody used cut — removing work rather than adding it.

Outcome

• ◆A project the company had counted as non-profitable — the CEO included — became its main income stream, with 80% of the company's people working on it.
• ◆Platforms used by 1.8M learners.

What I'd do differently

• ›Inherit the approaches, not the code. The platform was over-featured from the beginning, and a large refactor still carries all of that forward — I spent effort making inherited features maintainable before I had the standing to argue they should not exist.
• ›With the architectural decision to make again, I would take the parts and the approaches worth keeping and write a clean codebase around them, and I would make the case for cutting scope at the start rather than a year in.