Engineering a Five-App Ecosystem
for Nigeria's On-Demand Economy

Nigeria's on-demand economy is among Africa's fastest-growing — but it's also among its most operationally complex. Consumers expect Uber-speed delivery. Riders need seamless dispatch. Vendors require inventory and order management. Employers need to coordinate task-based workforces. No single off-the-shelf solution handles all of this simultaneously, and the fragmented tools that exist create friction at every handoff.

Nexora was engaged to design and architect Scooty XP from the ground up — not as a single app, but as a coordinated ecosystem of five role-specific applications that share a unified backend, a consistent design language, and a real-time operational layer. The goal was a platform that could compete with Bolt Food and Jumia on user experience while operating at the infrastructure sophistication of a Series B logistics startup.

• Architect five distinct apps that behave as one cohesive platform
• Design role-specific UX flows without sacrificing cross-app consistency
• Engineer real-time dispatch and order state synchronisation across all user types
• Build a marketplace infrastructure ready to scale from MVP to commercial growth

Building a single high-quality mobile app is a significant undertaking. Building five simultaneously — each serving a distinct user type with its own mental model, workflow priorities, and real-time data requirements — is an architectural challenge of a different order. The risk wasn't just poor UX. It was operational collapse: orders going unacknowledged, riders receiving stale dispatch data, vendors unable to manage incoming volume. In a market as competitive and impatient as Nigeria's logistics sector, those failures translate directly into lost customers and dead growth.

Role Fragmentation Without Coherence

Each of the five user roles — customer, rider, provider, shop, worker — has entirely different success metrics and interaction patterns. A customer wants speed and transparency. A rider needs frictionless navigation and clear earnings visibility. A vendor needs to manage orders without leaving their counter. Designing five experiences that feel equally purposeful without becoming five separate products required a unified design system enforced across every app from day one.

Real-Time State Across Distributed Sessions

When a customer places an order, at least three other apps must respond simultaneously — the nearest available rider receives a dispatch ping, the vendor receives an order notification, and the platform's assignment logic must evaluate availability and route optimality in under two seconds. Any latency or state mismatch breaks the contract the platform makes with its users. Engineering this level of synchronisation on infrastructure suited to Nigeria's variable connectivity was the platform's defining technical constraint.

Marketplace Scalability from Day One

Scooty XP launched with ambitions beyond a single city. The architecture needed to support multi-city expansion, multi-vendor onboarding, and new service verticals — without requiring architectural rebuilds at each growth stage. Building for scale when the initial user base is still small is an exercise in disciplined restraint: choosing infrastructure primitives that don't constrain the future, even when simpler solutions would ship faster.

Before any wireframe was drawn, Nexora spent the discovery phase mapping the operational flow of a complete order lifecycle — from the moment a customer taps "Order" to the moment a rider marks a delivery complete. Every decision a user makes, every notification the system sends, every state change the backend records was mapped as a first step. Only by understanding the full operational logic could the team design UX that genuinely supported it rather than approximated it.

Role-Specific Mental Model Analysis

Each user type was studied through the lens of their core job-to-be-done. A customer's job is to receive something reliably and quickly. A rider's job is to maximise productive hours while minimising wasted navigation. A vendor's job is to fulfil orders without disrupting their physical operation. These aren't UX personas — they're workflow realities that determined every screen layout, every CTA position, and every notification strategy within each app. The rider app, for instance, was designed to be operable with one hand while mounted on a motorcycle; the shop app was designed for tap-first interactions from behind a counter.

Shared Design System Architecture

To maintain coherence across five apps without duplicating design work, the team established a shared component library before building any individual screen. Colour, typography, spacing, button states, card structures, map overlays, and notification patterns were all defined centrally. This meant each role-specific app felt like Scooty XP, not like five different companies using the same name. It also drastically reduced the iteration cycle — a change to the core card component propagated consistently rather than requiring five separate updates.

Real-Time-First Backend Planning

The system was designed around the assumption that real-time synchronisation was not a feature — it was the product. Firebase was selected not because it was the easiest backend choice, but because its real-time database model natively supports the bidirectional state propagation that logistics dispatch requires. Every data model was designed with concurrent read/write patterns in mind, ensuring that order state changes triggered the correct downstream events in every connected app without manual polling.

The visual direction for Scooty XP was built on a single principle: energy with clarity. Logistics apps live in high-stakes moments — a rider deciding whether to accept a run, a customer watching their order move in real-time, a vendor processing three orders simultaneously. The UI needed to communicate information instantly without creating cognitive load. That meant bold typography, clear hierarchy, and restrained use of colour so that accent signals — a new order ping, a delivery complete badge — cut through without competing with ambient interface noise.

Colour System

Typography

A geometric sans-serif primary typeface was selected for its legibility at small sizes on mobile screens — critical when a rider is reading dispatch details at speed. Numerical data (distances, earnings, order counts) was set in a tabular-figures variant to prevent layout shifts as values update in real time. All body copy targets a minimum 16sp size to accommodate ambient-light reading conditions common in Nigeria's outdoor delivery environment.

Design Principles

The UX challenge unique to multi-role platforms is that no single user experiences the full system — but the system must work perfectly for all of them simultaneously. Every UX decision Nexora made was evaluated against its downstream effect on the other four apps. A friction point in the customer booking flow creates idle time for riders. A confusing vendor order management screen creates delayed fulfilment. The experience design was, by necessity, systems design.

The Customer Flow: Discover → Order → Track → Receive

The customer app's primary conversion path was designed to reach "order confirmed" in under four taps. Discovery surfaces the nearest available services and featured vendors with social proof baked into the card layout. Checkout uses a persistent summary drawer rather than a full-page interruption, keeping the user in flow. Post-order, the live tracking view becomes the primary screen — map-centred, with minimal UI chrome — because once an order is placed, the customer's only job is to wait with confidence.

The Rider Flow: Available → Accept → Navigate → Deliver

The rider app is built around a single decision moment: accept or decline a dispatch. That screen gets the largest text, the clearest earnings preview, and the fastest response window in the entire product suite. Once accepted, the UI transitions immediately to turn-by-turn navigation. Earnings, completed runs, and ratings are surfaced at session end — never during an active job, where they create distraction rather than motivation.

The Vendor Flow: Receive → Confirm → Dispatch → Report

Shop and Provider apps were designed for operators running physical businesses. The order queue is the home screen — full-width, chronological, with colour-coded urgency states. Confirmations are single-tap. Dispatch handoff to a rider is automated where possible, manual where the vendor prefers control. End-of-day reporting is available without navigating away from the operational view, supporting reconciliation habits already established in the vendor's existing workflow.

The most critical technical decision made early in the project was the choice of React Native for all five apps. The alternative — native Swift and Kotlin development — would have required two separate codebases per app, or ten codebases total. React Native's cross-platform model halved the implementation surface while maintaining near-native performance on both iOS and Android. The shared component library built on top of it meant UI consistency was enforced at the code level, not just the design level.

Frontend Architecture

• React Native — single codebase compiled to native iOS and Android for all five apps
• Shared component library enforcing design system at the code level across all apps
• Role-based navigation architecture — each app exposes only the screens relevant to its user type
• Map integration via Google Maps SDK with custom overlay layers for dispatch visualisation

Backend & Infrastructure

• Node.js + Express — RESTful API layer with modular route architecture for service separation
• Firebase Realtime Database — chosen specifically for its bidirectional sync model, eliminating polling and enabling instant cross-app state propagation
• Firebase Authentication — unified auth layer across all five apps with role-claim JWT tokens
• Cloud infrastructure with auto-scaling to handle demand spikes during peak delivery windows

Real-Time & Operational Systems

• Firebase Cloud Functions handling dispatch assignment logic serverlessly — no dedicated dispatch server to maintain
• Geolocation services with continuous rider position streaming and proximity-based matching
• Push notification infrastructure via Firebase Cloud Messaging — coordinated across all five app roles

Integrations

• Payment gateway integration supporting card payments, mobile money, and cash-on-delivery reconciliation
• Google Maps Platform — Directions API for routing, Places API for address resolution, Maps SDK for live tracking
• App Store Connect + Google Play Console — coordinated five-app submission and review management