Lupply
Still operated by CPXA multi-sided commerce platform — point-of-sale, inventory, kitchen production, wallets, payments, marketplace storefronts and last-mile delivery — across five connected products on one Go backend.
- Client
- CPX Limited (own product)
- Role
- Architecture, engineering and day-to-day operations
- Outcome
- Live and operated daily
- Go
- Fiber
- GraphQL
- MongoDB
- Redis
- Flutter
- Next.js
Lupply is the reason we can say we operate what we build. It is ours: we designed it, we wrote it, we deployed it, and we are the ones who get called when something breaks at the weekend.
What it actually is
Five connected products sharing one backend:
- Lupply — business management for merchants: point-of-sale, inventory, staff and roles, kitchen production, catalogue, reporting.
- Lupply Food — the consumer marketplace, where merchants publish storefronts.
- Lupply Ride — delivery fulfilment: dispatch, rider assignment, live tracking, settlement.
- Store and Gas — further marketplace verticals on the same catalogue and wallet.
- Admin — the operations console: metrics, marketplace monitoring, exception handling.
They run on 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.
The unglamorous parts
The interesting engineering in a commerce platform is almost never the screens.
Money has to reconcile. Every order carries a sum that must hold across the customer's payment, the merchant's payout, the rider's earnings and the platform's commission. Discounts, delivery fees, wallet credit and pay-on-delivery advances all move that sum around, and a receipt that does not balance is a support ticket at best.
Offline is the normal case, not the edge case. A market stall's point-of-sale has to keep selling when the network drops, which means every sale needs an identity generated on the device, a queue that survives a restart, and a merge that cannot duplicate a transaction when the connection returns.
Dispatch is a scheduling problem with physics. Riders have vehicles, capacities and locations; orders have pickup windows, multiple stops and customers who are watching a map. Quoting a delivery before the rider exists, and honouring that quote afterwards, is harder than it sounds.
Multi-tenancy has to be airtight. Merchants can run several businesses and branches. Every query in the system has to be scoped, and a single unscoped one is a data breach.
Why it matters for your project
Those problems do not change much between one market and another. A payment reconciliation bug in Warri behaves exactly like a payment reconciliation bug in Manchester. The engineering transfers — and unlike a portfolio of handed-off projects, we are still living with every decision we made.