Apperture was the first role where I was effectively the whole frontend function. The product was a QR-based restaurant ordering and payment platform used across Singapore, and I inherited a codebase that had grown without much structure.

Each page had effectively become a single giant file, component boundaries were weak, and Redux Saga was being used in ways that made the app harder to reason about than it needed to be. Before adding much new functionality, I refactored the product into a cleaner atomic structure so future work could stop fighting the foundations.

The most obvious technical problem was menu performance. With only about 30 image-heavy products, the app dropped into the 15 to 20 fps range. I implemented virtualisation and targeted memoisation, then stress-tested the result with 1,000+ items across multiple categories until it held at a locked 60 fps.

After the performance ceiling was gone, I expanded the product surface: AMEX and other payment gateways, multi-language support, allergen information, and Singapore HPB health-grade labels. Those features sound separate on paper, but each one touched assumptions buried across the app.

The hardest build was "pick menu first, scan table later." The original app assumed table context existed from the first second of a session, so introducing a late-arriving table ID broke assumptions everywhere downstream. I rebuilt the session state so both journeys could coexist without contaminating each other.

Apperture reinforced a pattern that has become central to my work: the frontend job is often really a product-systems job. You fix performance, shape state architecture, smooth the UX, and sometimes quietly repair the business model assumptions embedded in the code.