Customer requests
Pickup, destination, delivery details, pricing review and scheduled requests give the customer a structured starting point.
RiderGuy / Delivery & digital services
A delivery connects a customer, a rider and the people managing the service. We built customer and rider Android applications, supported by a shared delivery platform and an operations workspace.
Visit the public websiteThe business need

A customer needs to request a delivery and understand what happens next. A rider needs a clear offer, the pickup and destination, and the steps required to complete the work. Operations needs visibility when a delivery changes or needs attention.
Those are different responsibilities in one journey. We connected them through separate applications that use the same order, assignment and delivery records.
The current products include native Android applications for customers and riders, an operations administrator and the public marketing website. The focus here is the implemented delivery workflow.



Existing repository listing artwork made from Android device captures. Test orders, routes and fares demonstrate the interface; they do not represent customer activity, performance results or current service pricing.
What we built
Customer, rider and operations tools support different parts of the same service.
Pickup, destination, delivery details, pricing review and scheduled requests give the customer a structured starting point.
Availability, incoming offers and delivery steps help riders see the work and manage the next action.
Assignment controls connect eligible riders to orders, with checks around payment and scheduled delivery timing.
Delivery status, available location updates and retained order records help customers follow their requests.
Order payments, receipts, wallet records and controlled payout workflows connect money to the activity behind it.
Administrator workspaces bring client and rider management, delivery review and customer support into the service.
What the system makes possible
A request carries its context from the customer to the rider and into operations. Each person can work from the relevant order and status, while support has a record to investigate when something needs attention.
This is the kind of structure a service business needs behind its customer experience: clear roles, connected records and a defined way for the work to move.
The public website is live. Application images are existing listing captures with test data. App distribution, feature availability and service coverage are controlled by RiderGuy; this page does not claim that every feature is publicly released.
Explore digital product systemsBuilding a service with several moving parts?
Tell us who uses your service, who delivers it and where the handovers become difficult.
Next project / De-Florishtop Afrik →