Amit Sharma.
All work Case study · Apptunix

A modular super app, instead of one build per client

A task-first concept for Modular Super App delivery partners: clearer requests, sequenced pickups, visible earnings and resilient status updates in the moments that matter.

Role
Lead UI/UX & Product Designer
Duration
Dec 2018 — Feb 2022
Team
25+ team members
Scope
Modular super-app ecosystem
Modular Super App marketplace ecosystem shown across vendor dashboard, customer web and mobile interfaces
The wider Modular Super App ecosystem spans customers, vendors, administrators and delivery partners. The redesign concept below focuses only on the delivery-partner experience.
superapp.io

One Platform, Every Surface

Every panel, app, and website that makes up your marketplace. All built. All included. All yours from day one.

Product surfaces
Modular Super App Super Admin panel showing global users, orders, revenue analytics and active stores
Super Admin PanelGlobal ecosystem metrics, total users, orders, revenue and active store management.
Modular Super App vendor panel showing merchant gross sales, order metrics, customer stats and category catalog management
Vendor PanelMerchant module manager for Grocery, Pharmacy, Food, Shop, Parcel, Rental and order fulfillment.
Modular Super App customer app showing multi-service discovery, product details and checkout
Customer AppMulti-service discovery, product detail, basket and instant checkout.
Modular Super App delivery app showing dashboard, order requests, order details and rider profile
Delivery AppTask-first rider requests, active route navigation, earnings and cash holding.
Modular Super App customer website showing grocery categories, search and product offers
Customer WebsiteDesktop web discovery, category browsing, offers and customer account.

The operating context

Modular Super App is a multi-service marketplace supporting grocery, food, pharmacy, ecommerce, parcel and rental businesses. Each delivery update affects several people at once: the rider doing the work, the customer waiting, the vendor preparing an order and the dispatch team monitoring exceptions.

Delivery partners work in motion, often outdoors and under time pressure. They need to judge requests quickly, collect from more than one vendor, follow the right stop sequence, communicate progress and reconcile cash—sometimes with unreliable connectivity.

Project context: this work sits inside my Apptunix tenure, where I led UI/UX and product design across the modular on-demand portfolio, handling 100+ projects and managing a team of 25+ members.

People in the loop

  • Delivery partners — primary users
  • Customers awaiting an order
  • Vendors preparing pickups
  • Dispatch and administration teams

Publicly documented capabilities

  • Online and offline availability
  • Accept or decline new requests
  • Multi-vendor delivery
  • Status and payment updates
  • Cash-in-hand and order history
  • Multiple languages and themes
01 · Framing

Four questions should drive the experience

What should I do next?

One unmistakable task and one primary action, based on the current delivery state.

Where do I need to go?

The next destination first, with the full pickup and drop-off sequence still visible.

How much will I earn?

Estimated earning before acceptance, then a clear split between earnings and cash held.

What status should I update?

Only the valid next status, confirmed before it affects every stakeholder downstream.

Modular Super App customer app concept showing grocery, pharmacy, shop, food, parcel and rental modules
A single order can originate in different service modules, but the rider should not have to learn a different delivery workflow for each category.
02 · Journey

Organise the product around delivery states—not feature lists

  1. 01Register
  2. 02Go online
  3. 03Receive request
  4. 04Review & accept
  5. 05Navigate to pickup
  6. 06Confirm pickup
  7. 07Navigate to customer
  8. 08Complete delivery
  9. 09Update payment
  10. 10View earnings
Multi-vendor variation: review all stops → follow the pickup sequence → confirm each pickup → start the final delivery → complete the drop-off.
03 · Dashboard

Show the current task before everything else

The dashboard should not give equal weight to every feature. Availability, the active delivery, the next stop and new-order alerts belong above summaries and history.

  • Availability: a persistent online/offline control with an explicit state label.
  • Active delivery: the next pickup or drop-off and the action required there.
  • Today at a glance: completed deliveries, earnings and cash in hand.
  • Operational warnings: GPS, connectivity and delayed-vendor messages that persist until resolved.
Modular Super App grocery admin dashboard showing inventory, orders, stores, customers and delivery statuses
Admin dashboard. One operational view brings inventory, orders, stores, customers and delivery states together across the grocery module.
04 · Decision point

Make a request understandable before asking for commitment

Effort

Pickup distance, delivery distance, estimated completion time and the number of stops.

Complexity

Number of vendors, number of drop-offs and whether the order is scheduled.

Value

Estimated earning, payment method and any cash the rider will be responsible for.

Decision rule Accept and decline stay visible, large and separated from accidental taps.
Modular Super App module setup interface showing selectable business types
Different business types create different pickup conditions. The request card should translate that variation into comparable effort, complexity and value.
05 · Active delivery

A map-first screen with one clear action

  • Next destination and the complete multi-stop sequence
  • Vendor and customer contact actions
  • Compact order details and payment method
  • Current status in text and icon—not colour alone
  • Report-an-issue access without leaving the task
  • One primary action that changes with the delivery state
Safety principle: large one-handed controls and minimal typing reduce attention cost while the rider is on the move.
Modular Super App business settings for home delivery, takeaway and scheduled orders
Home delivery, takeaway and scheduled orders affect the route. The rider sees the resulting instruction—not the underlying configuration.
06 · Money

Separate earnings from money being held

Cash currently held

Cash collected on behalf of the platform, kept distinct from personal earnings.

Digital earnings

Completed delivery income, with a traceable order-level breakdown.

Pending settlement

Amounts awaiting reconciliation, due dates and the next required action.

Exceptions

Cash mismatches, disputed payments and failed updates surfaced as resolvable items.

07 · Resilience & inclusion

Design the failure states as carefully as the happy path

No requestsRider offlineGPS disabledConnection lostVendor delayedCustomer unavailableOrder cancelledIncorrect addressPayment mismatchStatus update failed

Critical status changes need confirmation. Offline and GPS warnings need to persist. Failed updates need a visible retry state rather than silently leaving customers and dispatch teams with stale information.

Modular Super App commerce interface with English and Arabic language selector
Language choice belongs in profile and setup, but delivery-critical labels should remain concise enough to scan quickly in every supported language.
08 · Validation plan

Proposed research

  • Contextual rider interviews
  • Ride-along observation
  • Prototype usability tests
  • Low-connectivity simulations
  • Multi-stop sequencing tasks

Honest outcome

  • No performance results are claimed
  • No internal analytics were available
  • Success depends on real-world validation

Next case study