One app, many services: building a super app for home services in Tunisia

The client

A Tunis startup running three separate service brands: home cleaning, appliance repair, and small-parcel delivery. Three apps meant three store listings competing for the same users, three logins, and marketing spend split three ways.

The problem

Users who booked a cleaning never discovered the repair service, because it lived in a different app. The company wanted what regional users already expect from apps like Careem: one account, one wallet, many services. The engineering risk of a super app is the opposite one: a monolith where every vertical's release blocks every other's.

The constraints

Cash is still king. Most Tunisian customers pay cash, not card. A wallet-only design would have excluded the majority of the market, and card-on-file adoption had to be earned, not assumed.

Three live brands, one install window. The three existing apps kept running until their replacements shipped. The super app had to reach store parity with all three before any of them was retired.

App store review risk. Apple's guidelines on super apps made the modular architecture a submission requirement, not just an engineering preference: one binary, independently reviewable service modules.

A thin core, fat modules

The core owns exactly four things: identity, payments and wallet, notifications, and chat between customer and provider. Each service vertical is a self-contained module with its own screens, booking flow, and release cadence. The cleaning team's release cannot break delivery.

Native, not wrapped

Built natively for iOS and Android. Booking flows, maps, and provider tracking are the entire product experience, and a wrapper's jank is exactly where users abandon a checkout.

Payments for a cash-first market

In-app wallet with card top-up and cash-on-completion recorded against the same ledger, because most Tunisian customers still pay cash. Providers see one balance regardless of how the customer paid.

One account, three discovery surfaces

The home screen surfaces all verticals to every user, which is the actual commercial point of a super app: a cleaning customer becomes a delivery customer without a new install, login, or payment setup.

Provider-side operations

Cleaning crews, repair technicians, and courier fleets got their own provider app with job acceptance, scheduling, and earnings against the same shared ledger, so marketplace supply scaled with demand. A shared job-matching service handles assignment and scheduling for every vertical, so a new service line inherits dispatch rather than rebuilding it.

Three apps became one

One listing, one account, one wallet. Marketing spend that had been split across three acquisition funnels now compounds on a single install.

Verticals ship independently

Each module releases on its own cadence. No vertical's launch has ever been blocked by another's release, which was the explicit failure mode the architecture was built to prevent.

Cash and card in one ledger

Providers are paid from one balance whether the customer paid cash or card, removing the reconciliation work that split payments used to create.