Skip to content

Flagship · Operated by CPX

The platform we point at when someone asks whether we can do this.

Lupply is ours. We designed it, wrote it, deployed it, and we are the ones who get called when something breaks at the weekend.

Lupply point-of-sale product grid
Lupply point-of-sale cart and tender
Lupply order confirmation
Lupply Food consumer marketplace

Real captures from the live system, not mockups.

Five products, one backend.

A single Go service using Fiber, GraphQL and REST, backed by MongoDB and Redis, with Flutter apps on iOS, Android, Windows and web, and Next.js panels on top.

The interesting engineering is never the screens.

These are the problems that took the time — and the ones that transfer directly to whatever you are building.

Money that reconciles

Every order carries a sum that must hold across the customer's payment, the merchant's payout, the rider's earnings and platform commission — through discounts, delivery fees, wallet credit and pay-on-delivery advances.

Offline as the normal case

A market stall keeps selling when the network drops. Every sale gets an identity generated on the device, a queue that survives a restart, and a merge that cannot duplicate a transaction on retry.

Dispatch with physics

Riders have vehicles, capacities and locations; orders have pickup windows, multiple stops and a customer watching a map. Quoting a delivery before the rider exists — and honouring it after — is the hard part.

Airtight multi-tenancy

Merchants run several businesses and branches. Every query has to be scoped to the right one, and a single unscoped query is a data breach.

Those problems do not change much between markets.

A payment reconciliation bug behaves the same wherever it happens. The engineering transfers — and unlike a handed-off portfolio, we are still living with every decision we made.