How to Build a Super App: Lessons from Gojek, Grab & Careem

The myth of the day-one super app

Every few months a founder tells us they want to "build the Gojek of" their country — rides, food, groceries, parcels, bill payments and a wallet, all in the first release. I understand the instinct. I also have to be honest: this is one of the fastest ways I know to burn money.

In the AI era, building ten services is not hard. Code is cheap, and platforms that bundle rides, food and parcels already exist. What is hard is selling ten services and operating ten services at once — ten sets of supply, ten support queues, ten sets of unit economics — with one small team and one budget. Most founders cannot sell one service profitably yet. Ten will not fix that.

Do not rush to pay for a super app. If the business cannot survive its first months, the money you pay any developer — including us — creates no value, and you end up with a beautiful home screen of tiles nobody taps, and a founder who has lost heart.

None of the famous super apps started that way:

• Gojek began around 2010 in Jakarta as a call centre that connected customers with motorbike taxi (ojek) riders for rides and courier jobs. The app only arrived in January 2015, with a handful of services such as rides, delivery and shopping. Today it describes itself as a platform of more than 20 services and has merged with Tokopedia to form GoTo.
• Grab started in 2012 in Malaysia as MyTeksi, a taxi-booking app. It became GrabTaxi, added private cars and bikes in 2015, dropped "Taxi" from its name and launched GrabPay in 2016, and took over Uber's Southeast Asian business in 2018. Only around 2019 did it formally position itself as a super app.
• Careem was a car-hailing company in the Middle East. It used the infrastructure it had built for rides to add delivery and payment services. Uber agreed to buy it for $3.1 billion in 2019. In 2023 the "Super App" business was spun out into a separate entity, with e& taking a majority stake, while Uber kept the ride-hailing business.

The pattern: one high-frequency service first, then a network, then payments, then more services. The super app is the result of years of execution, not a version-one specification.

Reality check before you spend a dollar

If you cannot answer these for one service, do not add a second.

When does a super app actually make sense?

A super app spreads the cost of acquiring a customer across many transactions. That only works under certain conditions:

If the right-hand column describes your market, build a strong single-vertical business — on an architecture that can grow later.

Which vertical to launch first

The first vertical has one job: create a daily or weekly habit and a supply network you can reuse. Gojek and Grab both started in transport: rides happen often, need a fleet, and that fleet can later carry food and parcels.

Pick the vertical where you have an unfair advantage, and where the supply you build can serve vertical number two.

The wallet and payments layer

A wallet lets customers top up once and spend across services, lets you pay drivers and merchants fast, and shows you spending behaviour. Grab launched GrabPay in 2016, years before calling itself a super app, and Careem used its ride infrastructure to add peer-to-peer transfers and prepaid credit before launching Careem Pay in 2022.

But a wallet is where your app stops being software and becomes a regulated financial business. In most markets, holding customer money or issuing e-money requires a licence or a licensed partner. The Bank for International Settlements has written about this tension: big tech in payments brings efficiency and inclusion, but also concentration and stability risks, and regulators respond accordingly.

Options, from simplest to hardest:

1. Payment gateway only. Card, mobile money or cash; you hold no balances.
2. Closed-loop credits. Refunds and promotions as in-app credit. Some regulators treat even this as stored value.
3. Partner wallet. A licensed e-money issuer or mobile-money provider inside your app.
4. Your own licence. Capital requirements, compliance staff, audits and time.

Most founders should start at option 1 or 3 and pursue a licence only when volume justifies it. Talk to a local payments lawyer before you design flows that hold money.

Building the partner network

A super app is a three- or four-sided marketplace, and every side needs selling, onboarding and support.

• Drivers and riders: fast but verified onboarding; reliable, quick pay; a transparent ledger of what they owe and are owed in cash-heavy markets; and the ability to take several job types so hourly earnings rise.
• Merchants: a simple panel for menus, availability and payouts; commission that reflects what you actually deliver; lots of hands-on onboarding. Density in one area beats thin coverage.
• Service providers: scheduling, skill verification and quality control rather than real-time dispatch.

Cross-selling economics

The argument: once a customer trusts your app and has a payment method stored, a second service costs far less to sell than a new customer. Shared supply helps too. Measure whether it is true:

• Cross-service adoption — share of service A customers who used B in the last 30 days
• Contribution margin per service — a vertical "subsidised by the ecosystem" is a cost, not a strategy
• Supply utilisation — are riders busier per hour after adding a job type?
• Retention by number of services used
• Promotion dependence — if cross-selling only works with heavy discounts, you are buying trial, not habit

Tech architecture: one customer app, one partner app, modular services

Principles: a shared ledger from day one, even before a wallet; feature flags by city and zone; modular, not microservice-heavy for a small team; and low-bandwidth tolerance for partner apps on budget Android phones.

For custom builds we use Flutter (GetX) for the customer and partner apps, React or Next.js for merchant and admin panels, Node.js for most services and Go where ride dispatch needs high-concurrency real-time matching, with PostgreSQL, WebSockets and Firebase Cloud Messaging underneath.

Insider tips: costs that multiply with every service

Every vertical you add multiplies your OTPs, map calls and server load. Get these right on service one.

• OTP over WhatsApp where it is cheaper. Meta charges per delivered WhatsApp Business Platform message, by category and country, since 1 July 2025, with a dedicated authentication category, per Meta's pricing page. Compare its rate card with your SMS gateway country by country — some markets carry higher international-authentication rates — and keep SMS as a fallback.
• A hybrid maps stack. As of October 2026, Google Maps Platform gives 10,000 free calls per SKU per month, then charges $7 per 1,000 Dynamic Maps loads and $2.83 per 1,000 Autocomplete requests, per Google's pricing list. Across several services that adds up fast. Combine MapLibre and OpenStreetMap for display, a cheaper geocoder (Mapbox's Temporary Geocoding API is free up to 100,000 requests a month, per Mapbox pricing) or a regional provider such as Barikoi, and self-hosted OSRM routing. Keep Google where it is clearly better, and cache everything.
• Start on a VPS. One well-sized server from Hetzner, Contabo, DigitalOcean or Vultr runs a single-vertical launch. Split services out when load demands it, not because the pitch deck says "microservices".
• CI/CD, backups and monitoring are non-negotiable. With several services sharing one core, a bad deployment breaks everything at once. Automated deploys, off-server backups and alerting before you add vertical two.

A realistic phasing plan

Skipping phases spreads a small team, budget and supply network too thin.

Super app readiness checklist

• We can name the single, high-frequency service we will win first.
• We have written answers to every reality-check question.
• We know who our supply is and how they will earn enough to stay.
• Our second vertical can reuse the same supply.
• We have taken legal advice on payments, stored value and transport rules.
• Our architecture has one customer app, one partner app and shared core services.
• We record every transaction in a ledger, even before a wallet.
• OTP, maps and hosting costs are modelled per order.
• We have a phase plan with exit criteria, not a version-one feature list.
• We have budget for operations, support and sales — not just development.

When Joldisoft is — and isn't — the right partner

We build ride-hailing, food delivery, home services and multi-service apps, mostly for founders in emerging markets. Our Gojek, Grab, Careem and Pathao style products show the multi-service structure, and our super app industry page explains how we phase builds. White-label with configuration starts from $3,000 if you want to validate one vertical first; custom super app MVPs start from $14,000; and we maintain what we build.

We are the right partner if you come with one vertical you can already sell, evidence of demand, a sales and marketing plan, an operations budget with runway after launch, and someone accountable for running each service. We will build that vertical well, on an architecture ready for the next one.

We are not the right partner if you want all services on day one with one budget, or if the build would use up the money you need to operate. We would rather tell you that now than watch the company close in six months.

We are looking for long-term partners whose businesses grow. Earn the right to be a super app one service at a time — and when you have earned it, we will be glad to build the next service with you.