In active development · Pilot cohort opening · delivery.posterita.com
The dispatch board your WhatsApp group has been pretending to be.
Delivery OS is the dispatch, driver, vehicle, and proof-of-delivery layer for shops and restaurants that run their own last-mile. We're building it in partnership with Yadea, the electric-vehicle manufacturer powering the fleet underneath. It is in active development today. We are opening the first pilot cohort to a small group of Mauritian restaurants and shops, and we would rather talk to you before you sign up than after.
A dispatch board built for shops, not warehouses.
Orders from your Retail OS till land in the DeliveryOS dispatch board the moment they are rung up. A manager picks a driver, watches the route, and closes the loop the moment the customer signs for the bag. No third-party broker, no aggregator fee, no screenshot of an order shared in a WhatsApp group at 12:47pm.
The big enterprise dispatch tools — Onfleet, Bringg, Routific — are designed for warehouses moving thousands of parcels a day, and priced accordingly. A neighbourhood restaurant doing forty deliveries a night does not need route optimisation across twelve depots. It needs to see who is on a delivery right now, who is free, and which order is late. That is what we are building.
A driver app that respects the rider's day.
The driver app is a small native surface for the person on the bike — pick up, navigate, capture proof of delivery with a photo, a signature, and a geolocated timestamp. That is the entire job, and the screen should look like it. No multi-tab dashboard, no notification storm, no upsell banner.
Riders are on phones in traffic, not on a desktop in an air-conditioned office. The interaction model is one-handed, high-contrast, big touch targets, and built to survive a screen with a delivery-rain smudge on it. Same philosophy that drives Retail OS on a POS terminal — the surface gets out of the way of the work.
Drivers as people, not just IDs.
The driver roster is the same shape as Retail OS staff management — one identity per worker, with shift state, availability, and what they are doing right now. A manager can look at the roster and see, in one line each: who is on shift, who is mid-delivery, who is back at the shop, and who is on break.
Dispatch breaks down the moment riders become rows in a spreadsheet. People take leave, swap shifts, change phones, quit. The roster treats every driver as a person you employ — because that is what they are — and the dispatch board reads from the same record. One source of truth from payroll to pick-up.
A vehicle that's not ready doesn't get the job.
Vehicle readiness is a daily check — battery state for Yadea electric vehicles, service-due flags, basic safety items. If a vehicle is not ready, it does not get assigned a delivery. The cost of finding out a bike is dead mid-route is paid by the customer waiting for cold food and the rider stuck on the side of a street.
This is where the Yadea partnership earns its keep. Yadea makes the vehicles; we build the software that knows their state. The same engineering team is responsible for the fleet and the dispatch layer, which is why battery-state telemetry, service intervals, and ready-for-shift logic show up as first-class fields rather than an afterthought.
Proof of delivery that survives a dispute.
Every drop captures a photo, a signature, and a geolocated timestamp. The record is append-only — no edits, no deletes, no "we redid the file later". When a customer disputes a delivery a week later, the answer is on file: it was delivered at 3:47pm to a person in a green shirt at this address, here is the photograph. Quiet, boring, unarguable.
The bridge from till to door.
Retail OS creates the order; DeliveryOS executes it. The till stays the source of truth for what was sold and to whom; the dispatch board picks up the order ID and tracks it from kitchen or pick-pack station to the customer's door. One customer object, one order ID, two products on the same Supabase backbone.
The boundary is a feature, not a limitation. Retail OS does not become a fleet-management tool, and DeliveryOS does not start owning the catalogue, the inventory, or the loyalty wallet. Each product does the job it is good at, and the order ID flows cleanly between them. When the delivery completes, the order in Retail OS closes — with proof attached, automatically.
Pilot first. Roll out together.
DeliveryOS is in active development. We are not pretending otherwise. The first pilot cohort opens to a small group of Mauritian restaurants and shops, Yadea-partnered for electric-vehicle fleets first, with the goal of getting the local conditions right — rider routes, building access, kitchen-to-pickup timing — before going wide.
What pilot means concretely: no cost while we tune the product against your real operation, a direct line to engineering instead of a support inbox, a monthly check-in with someone from our team, and your feedback going straight into the roadmap. In return, we ask for permission to learn from how your riders use the app and to write up what we learn so the next merchant benefits.
Questions people actually ask.
When does the pilot start?
We are opening the first cohort to a small group of Mauritian restaurants and shops in the coming months. The schedule depends on Yadea fleet readiness in your area and how many merchants are already in the queue. Register interest and we will write back with a real date, not a maybe.
Do I need a Yadea fleet to use Delivery OS?
No. The dispatch board, driver app, driver roster, and proof of delivery work with any fleet — your own motorbikes, a contracted rider, a mixed fleet. The Yadea integration is what makes vehicle readiness and battery state work end-to-end for electric vehicles. If you already run a Yadea fleet, you get extra signal. If you don't, the dispatch layer still does its job.
What about restaurants already on Yango Food or Bolt Food?
Those are different jobs. Yango and Bolt route orders from their app into your kitchen. DeliveryOS handles the orders you take yourself — phone, WhatsApp, walk-in, Retail OS till — and need to dispatch with your own riders. Most of the restaurants we talk to use both: aggregator apps for reach, DeliveryOS for their direct customers. We do not plan to compete with aggregators; we plan to make your own channel work properly.
How does pricing work during pilot?
Pilot merchants get DeliveryOS at no cost while we are still tuning the product against real local conditions. In exchange we ask for direct feedback — a monthly check-in, a direct line to engineering, and permission to learn from how your riders actually use the driver app. When DeliveryOS exits pilot, you will get advance notice and a fair commercial price aligned with Retail OS pricing tiers.
What if my drivers don't all have phones?
The driver app is the primary surface, but the dispatch board is designed so a shop manager can run the loop manually for riders without smartphones — assign by name, mark picked up, mark delivered, capture proof on the manager's device. We are not going to pretend every rider in Mauritius has a top-end Android. The product respects that.
Will it work outside Mauritius?
The architecture is portable — the same pattern that runs Retail OS across markets. We are starting in Mauritius because Yadea fleet operations are concentrated here and we can iterate inside one regulatory environment. Once the pilot stabilises, the next markets are the ones where Retail OS already has merchants and where local last-mile logistics are mostly self-run rather than aggregator-dominated.
Does DeliveryOS replace my Retail OS till?
No, and it is not supposed to. Retail OS stays the source of truth for what was sold, to whom, and at what price. DeliveryOS picks up the order ID and tracks it from kitchen or pick-pack station to the customer's door. When the delivery closes, the order in Retail OS closes with proof attached. The boundary is intentional — neither product needs to become the other.
Stop running dispatch in a WhatsApp group.
If your current dispatch flow is a chat thread, a paper logbook, and a manager keeping it all in their head, we should talk. DeliveryOS is being built for exactly that operation — register interest, and we will line you up for the first cohort.
App will live at delivery.posterita.com once we exit pilot.
The Posterita family
Retail OS runs the till. Agency OS supervises the agents. Legal OS files the company. Mail OS reads the inbox. Account OS holds the identity. Commerce OS turns the chat into a checkout. Delivery OS executes the last mile. One team, one compliance posture, an operating system for SMEs in the developing world.
Posterita Ltd is registered in the Republic of Mauritius. Yadea DeliveryOS is built in partnership with Yadea, the electric vehicle manufacturer. Read our privacy policy and terms.