Enterprise · SaaS
Arabic-first point of sale with live barcode price sync.
An Arabic-first point of sale built around real pharmacy workflows.
Pharmacy staff needed fast, error-free checkout in Arabic — with prices that stay correct as suppliers change them.
Most software that 'supports Arabic' is English software mirrored at the last minute — flipped layouts, machine-translated labels, numbers sitting awkwardly against text running the other way. That approach falls apart at a pharmacy counter, where staff need fast, error-free checkout in Arabic and hesitation at the till turns into a queue. So this build went the other way: right-to-left from the first screen. The interface was designed Arabic-first rather than translated after the fact — and because I'm a native Arabic speaker, the interface language is written, not machine-translated. Arabic isn't the add-on here; it's the foundation.
The quiet failure mode of a pharmacy till is a stale price. Suppliers change their prices; a static price database doesn't know that, and eventually the shelf and the till tell the customer two different numbers. That's not just a checkout error — it's a trust problem, and it gets settled at the counter, in front of a queue.
The design decision was to remove the duplicated manual step. Price synchronization runs live, so the till never depends on someone remembering to re-key a supplier's update. One price list, one source of truth — and when it changes, the counter changes with it. That is what 'shelf and till never disagree' actually means in the architecture.
At a busy counter the interface has to disappear. The workflow treats the barcode scanner as the primary input: scan, price, sell, next customer. The build prioritises keeping typing and menu-hunting out of the critical path, and the screens are laid out for daily counter use — what the person at the till needs in that moment, and nothing competing with it. Speed here isn't a benchmark number; it's the absence of steps.
The owner's side exists because shops so often track sales in one place and stock in another — usually a spreadsheet that starts drifting the day after it's updated. Here, sales flow through the same system that watches inventory, so the sales and inventory dashboards describe the same reality the counter just created, with no separate reconciliation step built into the routine.
It also reflects the model I build to: a custom POS is a one-time build the business owns — its brand, its data — not software rented monthly from a platform. For anyone weighing a similar build, that's the takeaway: start from how your counter actually runs, and end up owning the system that runs it.
All projects — Emad Yahya, web developer in Dubai · Live project · Next project: Online Booking Platform · emaadyahya4@gmail.com