Interflext (PVT) Ltd
A multi-platform POS platform for restaurants, retail stores, and business operations, built to support real daily store workflows across Android, Windows, and Apple devices.
Core contributor within the product team, focused on sync reliability, race conditions, performance bottlenecks, and staff-facing operational workflows.
01 · Context
HowToPay POS is an existing company product used for day-to-day selling and store operations across multiple device types. I joined after the initial application had already been built, so the case study is about contribution inside a production system rather than sole product ownership.
My work concentrated on the failures that become expensive in a live POS environment: bidirectional sync, concurrent scheduled orders, operational tasks that happen every day, and staff screens that slow down when real data volume arrives.
02 · Constraints
A store cannot stop selling because connectivity changes, so order and operational state needs reliable behavior across offline and online transitions.
Scheduled orders and background queues create concurrency boundaries where race conditions can surface as duplicated, missing, or inconsistent state.
Staff-facing screens have to remain usable with large order and floor-plan datasets; memory pressure and long loading states directly affect daily operations.
03 · Ownership
Contributed as a mobile engineer within the wider HowToPay POS product team; I did not originate or solely own the overall product, backend, commercial scope, or every POS workflow.
Owned specific reliability work around offline-to-online and online-to-offline synchronization, order-state consistency, and scheduled-order queue race conditions.
Implemented operational automation such as automatic midnight cash-shift close and investigated/fixed memory lag, frozen states, long loaders, and slow high-data floor-plan or existing-order views.
04 · Engineering decisions
The reliability work focused on preserving coherent order and operational state as connectivity changes rather than treating offline/online as a simple boolean UI mode. Sync paths need to agree on what happened, what is pending, and what can safely be applied.
Scheduled-order issues were approached as race conditions around queued work and state transitions. The goal was to remove timing-sensitive behavior instead of masking inconsistent results later in the UI.
Automatic cash-shift close at midnight moves a repetitive daily responsibility out of staff memory and into deterministic product behavior, reducing one source of store-side inconsistency.
Slow floor-plan and existing-order experiences were treated as performance and memory problems first. The work targeted loading, frozen states, and data-heavy rendering rather than only changing visual feedback around the delay.
05 · Hard parts
A POS can move between offline and online operation while staff continue to create real business state. Reliability work has to preserve order continuity through those transitions without assuming ideal connectivity.
Concurrency bugs are difficult because the same flow can look correct in ordinary testing and fail only when queue timing overlaps. The fix required reasoning about ordering and state transitions rather than one screen in isolation.
Floor plans and existing-order screens can accumulate enough data to expose memory lag, long loading indicators, or frozen interactions. Production performance work had to focus on the paths staff touch repeatedly during a shift.
06 · Outcome
Resolved concrete sync, race-condition, and high-data performance problems inside a live multi-platform POS product.
Automated the midnight cash-shift close flow so a recurring store operation no longer depends entirely on a manual step.
The case study keeps the company product scope separate from my contribution and intentionally avoids using changing client counts as a personal engineering metric.
07 · Product walkthrough
16 published screenshots from the product. Open any frame to inspect it at full size.
Stack