Rethinking a decade of software without breaking what already worked.
mSRC (Mobile School Report Card) has been part of Ghana's education ecosystem since 2016. Over the years the platform grew alongside its users — new requirements were added, workflows evolved, and the interface gradually became more complex.
In 2026 I led the redesign of the mobile application — not to make it prettier, but to make it simpler.
One of the hardest parts of redesigning mature software is resisting the temptation to start over.
The existing application already worked. Teachers understood it. Processes depended on it.
The challenge wasn't replacing years of work. It was preserving institutional knowledge while removing years of accumulated complexity.
Every screen in the existing app had a reason for existing — someone had asked for it, at some point, to solve a real problem. That made the redesign less about deleting features and more about earning the right to remove each one, without breaking a workflow a headteacher relied on every week.
Before designing screens, I spent time understanding how different users actually interacted with the application. Questions became more important than mockups:
- Which screens were confusing?
- Which information wasn't needed?
- What decisions happened every day?
- Which workflows had become unnecessarily complicated?
The redesign focused on removing friction. Examples included:
- Simplifying PLC workflows
- Reducing unnecessary navigation
- Redesigning assessment reporting
- Improving terminology
- Creating a calmer visual hierarchy
Every screen had one question: can this be simpler?
The system spans a React/Next.js web surface for administration and reporting, a Flutter mobile application for the redesigned headteacher experience, and a Laravel/PHP backend on MySQL, with Redis handling caching and session state under daily load from schools nationwide. The redesign had to hold that structure steady — no rewrite of the data model, no migration risk — while the client experience changed underneath it.
Instead of treating AI as a code generator, I used it throughout the product lifecycle:
- Challenging UX assumptions
- Reviewing workflows
- Generating implementation ideas
- Analysing edge cases
- Accelerating development
Every engineering decision still required human judgement. AI simply made iteration dramatically faster.
The redesign shipped incrementally, workflow by workflow, rather than as a single rewrite — so schools already depending on mSRC never lost the app mid-transition. Reporting and PLC workflows were prioritised first, since they carried the most accumulated complexity and the most daily use. A GitHub Actions CI/CD pipeline made that incremental approach safe to ship — every change tested and deployed the same way, rather than trusted to a manual release process.
The hardest calls weren't technical — they were about what to leave alone. It's easy to simplify a screen nobody uses; it's much harder to simplify one that hundreds of headteachers open every morning without disrupting their routine in the process.
Building software is exciting. Improving software is harder.
Good products aren't built by adding features. They're improved by removing unnecessary decisions.
The redesign established a cleaner foundation for future improvements while preserving the workflows schools already depended on.