Hospitality & retail

Omni Channel POS

Point of sale platform

Omni Channel POS is a full point of sale platform for restaurants and retail, and we built across the whole suite: the Android terminal that runs the till, the merchant back office behind it, the customer-facing ordering storefront, and the console the platform team uses to run the business. Four products, one shared data model, and a sync layer holding them together whether or not the internet is up.

Our role: Android engineering · Full-stack web · Platform architecture · Design system · DevOps
Platforms: Android · Web · Self-service kiosk
Stack: KotlinJetpack ComposeRoomHiltNext.jsReactNode.jsExpressMongoDBSocket.IOTurborepoDockerAWS

The problem

Problem.

A till cannot wait for the network. It has to take an order, split a bill, fire a ticket to the kitchen and print a receipt while the broadband is down and a queue is forming, then reconcile everything the moment it reconnects, without losing an order or double-charging anyone. Layer on four products that all read and write the same menu, staff and inventory data, and the hard part stops being any single feature and becomes keeping them all in agreement.

What we built

Solutions.

Not a feature list, the pieces that had to exist for the product to do what it claims.

The Android terminal

The in-store till: ordering, floor plan and table management, split bills by item or by seat, cash management, day close, batch settlement, and a self-service kiosk mode. Multi-module clean architecture across 33 Gradle modules.

A receipt and kitchen printing framework

Printing is where POS projects usually go to die. We built a section-based renderer (header, items, tips, payment detail, summary, refund, footer) with data-driven styling, so a receipt layout is configuration rather than a rewrite. Kitchen tickets get their own renderer.

Four printer transports behind one interface

Bluetooth, USB, LAN and default printers all sit behind a single manager, with two driver stacks underneath: a vendored ESC/POS implementation with barcode and QR encoders, and the Star Micronics SDK for Star hardware and cash-drawer kick.

Merchant back office

Menu and modifier management, staff, shifts, payroll and time clock, inventory with wastage and stock counts, purchase orders and vendors, promotions, gift cards, and a reporting suite where every report has a matching export.

Online ordering storefront

The customer-facing side: browse, cart, checkout, payment and order tracking, wired into the same menu the terminal serves so a price change lands in one place.

Platform super-admin console

How the business itself is run: merchants, locations, resellers, licences, subscriptions, hardware and APK distribution. Licensing is a first-class part of the product, not an afterthought. Most of the scheduled jobs exist to serve it.

Two design systems, one language

An in-house Android component library built twice on purpose (once in the View system, once in Compose, sharing colours, dimensions and typography), so screens migrate incrementally without the app looking like two apps.

Kitchen display and payments

A KDS with ticket rails, recall and online-order rejection, plus card payments across multiple vendors including tap-to-pay on the device itself.

We have had a positive experience working with Jay and his development team on a complex restaurant technology project. Jay has been responsive, dependable, and committed to understanding our business requirements while coordinating his team through a complex product-development process. We value the working relationship we have built and his continued commitment to helping move the project forward.

David Lopez, Founder & CEO, Modern Software Solutions LLC

Under the hood

The parts that were genuinely hard.

Offline-first sync, and what it takes to be honest about it

The terminal keeps its own database (39 entities, 27 hand-written migrations), and every write goes through a durable outbound queue rather than straight to the network. Inbound batches apply with per-item exception isolation so one malformed record can't stall the waterfall behind it, and anything that fails lands in a dead-letter table instead of vanishing. The sync cursor only advances over records that actually applied, which is the difference between a queue that drains and a queue that lies.

Terminals that find each other without the cloud

Tills in the same store discover one another over UDP broadcast, hold a private message socket, and run heartbeat checks between themselves. If the internet is gone but the LAN is fine, the terminals still agree with each other, which is the situation that actually happens in a restaurant, and the one a cloud-only design handles worst.

Order conflicts as a modelled state, not a bug

Two terminals editing the same order while offline is not an error condition, it's Tuesday. Conflicts get their own table, their own resolution use case, and re-evaluation when new information arrives, so the system converges deliberately instead of letting the last writer win.

Real-time as the default transport

Socket.IO carries more than fifty event types, with terminals authenticating by licence key and joining a room keyed to their location, and web clients joining by user. A bidirectional mapping layer translates between the terminal's shape of an object and the back office's, so neither side has to adopt the other's model.

Infrastructure sized to the failure you expect

Two identical production application servers with elastic IPs and a database on a private subnet reached only through a bastion hop. Deploys are path-filtered so only changed services rebuild, tagged by commit, and the last two versions stay on disk, because the rollback you can perform in thirty seconds is worth more than the one you have to rebuild.

Load testing by impersonating the estate

A purpose-built harness loads a merchant's real locations, licences and menus, then opens one socket client per licence to pose as a terminal and drive synthetic order and kitchen-ticket traffic, so the sync layer gets stressed the way a busy estate stresses it, not the way a unit test does.

Previous projectELD MandateFleet compliance platform Next projectFTC SolarSolar tracker control systems

Got something like Omni Channel POS in mind?

Tell us where your business is stuck. We'll show you what an AI-native team can ship, and how fast.

Start a project contact@whyphyinfotech.com