The Challenge
The legacy retail POS had grown without an architectural pattern. In the sales module especially, the UI and the business logic were tightly coupled — presentation and rules lived together in the same monolithic code, with no separation between what the user saw and what the system did underneath.
In that kind of codebase, every new feature is a gamble: because everything is entangled, a change made for one requirement can silently break functionality somewhere else. Development slowed and risk rose with every addition.
The Approach
The goal was to introduce structure where there was none — and to do it in a way the rest of the codebase could follow.
- Introduced a properly structured MVVM pattern in the sales module, cleanly separating the UI (View) from state and behaviour (ViewModel) and the underlying business logic (Model), where previously no such separation existed.
- Established a template the team could reuse — once the first module proved the pattern, subsequent modules followed the same clean separation of concerns instead of repeating the old tangle.
- Continuously optimized the MVVM-based modules as they grew, keeping the structure clean rather than letting it erode over time.
The Result
The MVVM-based modules proved easy to maintain and issue-free. With presentation and logic separated, new features could be added without the fear of breaking unrelated functionality, and the pattern gave the whole team a consistent, predictable way to build. What began as one refactored module became the architectural standard the codebase grew into.