Three audiences, one order lifecycle
Designing customer, restaurant and rider apps over a single shared domain.
Demonstration content. This write-up is an illustrative example used while the site is being populated. The client is fictional and no figure here describes a real engagement.
Context
A delivery startup that needed three applications live at once, on unreliable mobile connections.
The challenge
Three interfaces over one order lifecycle usually becomes three implementations of it, which then disagree. Riders also lose signal constantly, and a lost status change means a phone call.
Our approach
A single codebase with three shells over one shared domain layer, so the lifecycle exists in exactly one place.
What we built
Rider actions queue locally and replay when the connection returns. Push delivery retries, so a status change eventually reaches everyone who needs it rather than being lost.
The outcome
The three parties coordinate through the app rather than by calling each other.
What we were aiming for
- One implementation of the order lifecycle
- Rider actions that survive losing signal
- Status changes that reach the other parties reliably
Tell us what you need
Four fields. A real person reads it and replies within one working day.
info@devnainc.com