How to build an app like Grab: the honest sequence from one service to a super app

Nobody funds a taxi app anymore, the pitch goes, so founders pitch the super app instead: rides plus food plus parcels plus payments, one app, one loyalty program, the Grab of somewhere. The pitch has a problem, which is that Grab did not build Grab that way. It shipped a taxi-booking product in 2012, added bikes when the market demanded them, added food and parcels once mobility frequency gave it an audience, and added payments once transaction volume justified rails. The super app is what the sequence produced, not what anyone built on day one.

This guide lays out how to actually build an app like Grab: choosing the wedge service, designing the platform spine so later services plug in rather than bolt on, the three-product reality of any marketplace build, the liquidity math that decides survival, what the build costs and who it needs, and the expansion discipline that separates compounding platforms from bloated apps.

It pairs with two companion pieces: the anatomy of a super app for how the finished organism works, and the Vietnam ride-hailing story for what happened when the model met a market with its own physics.

The first decision: build a sequence, not a super app

The phrase super app describes an end state: one application where a user rides, eats, ships, pays and borrows, held together by a shared identity and a shared wallet. End states are not build plans. Every super app that exists, Grab, Gojek in its prime, WeChat before either, got there by winning one high-frequency service first and then converting that frequency into permission to offer the next. The order matters because each layer funds and de-risks the one after it: rides prove the dispatch engine and build the driver network that delivery reuses; delivery builds merchant relationships that payments monetize; payments produce the transaction history that financial services underwrite against.

The practical consequence is that your first build is a single-service marketplace with a platform-shaped foundation, and the discipline is in both halves of that sentence. Founders who skip the first half build four mediocre services at once, splitting a seed-stage budget across four supply networks, four operations problems and four cold-start battles, and lose to anyone focused. Founders who skip the second half win their wedge on a codebase where user, payment and dispatch logic are welded to the rides feature, and then pay for the platform twice when service two arrives.

So the honest answer to how do I build an app like Grab is: decide the sequence. Which service is the wedge, what does winning it look like in numbers, what is the most likely second service, and what must the foundation share between them. Everything else in this guide, architecture, team, cost, expansion, follows from writing those four answers down before the first sprint.

• The wedge service. One high-frequency, underserved problem in one market. Rides and food delivery are the classic wedges because frequency is weekly or better.
• The definition of winning. A liquidity target in one city: pickup times, fill rate, repeat usage. Not downloads, not press.
• The probable second service. Named in advance so the spine is designed for it, even though it will not be built yet.
• The shared spine. Identity, payments, dispatch and data that every future service will reuse rather than reinvent.

Choosing the wedge: frequency first, then gap, then supply

The wedge service has one job: build a habit strong enough to carry a platform. That makes frequency the first filter. Rides and food delivery dominate super-app history because their natural frequency is weekly or daily; grocery, pharmacy and parcels follow close behind. Services used monthly, home cleaning, moving, repairs, can be good businesses but poor wedges, because a monthly habit does not generate the open rate that cross-selling needs. If your candidate wedge is low-frequency, the super-app framing is probably wrong for your project, and a focused vertical marketplace is the more honest plan.

The second filter is the gap: what does your market visibly lack or visibly resent. A wedge succeeds by being clearly better than the incumbent behavior, cheaper than the taxi mafia, faster than calling restaurants, more reliable than the informal courier on a corner. Markets with entrenched, well-run incumbents, including the global platforms themselves, are brutal wedge territory; markets where the incumbent is informality, negotiated prices, no tracking, no recourse, are where the model was born. This is why the interesting super-app stories keep coming from emerging markets, and why Vietnam's version rewarded localization over imported playbooks.

The third filter is supply-side reachability, and it is the one founders skip. Every marketplace cold-start is won on the supply side: drivers, couriers, merchants. A wedge is viable when you can realistically recruit, onboard and retain a few hundred suppliers in one city with the budget you have, which usually means an existing labor pool doing the work informally, motorbike taxis to formalize, restaurants already running their own delivery, rather than a supply base that must be created from nothing. Grab recruited the existing xe om economy; DoorDash recruited restaurants that already cooked. The wedge that requires inventing a profession is not a wedge.

The wedge test, five questions before the first sprint

• Is natural frequency weekly or better?Daily and weekly habits carry platforms. Monthly services make fine businesses and poor wedges.
• Is the incumbent informality or a giant?Beating no-tracking, negotiated-price informality is the born use case. Beating an entrenched platform on its own service is a capital bonfire.
• Can you recruit supply with the budget you have?A few hundred active suppliers in one city, drawn from an existing labor pool, is the realistic cold-start unit.
• Does the wedge generate reusable assets?A driver network, merchant relationships or payment volume that service two will inherit. A wedge that shares nothing forward is a dead end.
• Can you name the winning numbers?Target pickup time, fill rate and monthly repeat rate in city one. If winning is not a number, it will not be won.

The architecture: a spine of shared services, modules around it

The technical difference between an app that can become a super app and one that cannot is where the boundaries sit. The expandable version is a spine of shared platform services, identity and profiles, payments and ledger, dispatch and logistics, notifications, pricing and promotions, data, with each consumer-facing service built as a module that consumes the spine. Rides is a module. Food is a module you have not built yet. The spine does not know or care which vertical a job belongs to; it knows users, money movement, and the general problem of matching a task to a nearby supplier and tracking it to completion.

Three spine decisions deserve the most design attention. Identity: one account, one KYC state, one session across every future service, because re-registration is where cross-sell dies. Payments: even if version one only charges cards or takes cash, structure the money path as an internal ledger with pluggable payment methods, so the step from payment feature to stored-value wallet, the single most valuable migration in super-app history, is an extension rather than a rebuild; cash-heavy markets also need collection and driver-float accounting in this layer from day one. Dispatch: model the core object as a generic job with a location, a state machine and an assignee, specialized by job type, so the engine that assigns rides can assign food pickups and parcel routes with configuration rather than a fork.

What this does not mean is microservices maximalism on day one. A small team ships fastest on a modular monolith: one deployable, hard module boundaries, the spine as internal libraries with clean interfaces. The discipline that matters is in the boundaries and the data model, not in the number of deployables; a monolith with a clean job abstraction expands into services when scale demands it, while a tangle of premature microservices mostly generates operational overhead for a product with no users yet. The classic scaling failure, chronicled in every marketplace postmortem, is not starting with a monolith; it is welding vertical-specific logic into the spine so deeply that the second service requires surgery.

The spine, component by component

Identity service

One account, profile, KYC state and session for all current and future services. The asset cross-sell depends on.

Payment layer and ledger

Internal double-entry ledger with pluggable methods: cards, cash accounting, and later a stored-value wallet. The future bank.

Dispatch core

Generic job matching: a task, a location, a state machine, an assignee. Rides today; food pickups and parcels tomorrow, by configuration.

Pricing and promotion engine

Fare calculation, surge logic, discounts and referral credits, shared so every service prices and promotes with the same machinery.

Notification and comms

Push, SMS fallback and in-app messaging, centralized because every service pings the same user.

Data platform

Events from every module in one warehouse. Cross-service behavior data is the evidence that times expansion and later underwrites financial services.

The build is three products: consumer, supply and operations

Founders picture the consumer app because that is the product they use. The build that clears a market is three products, and the consumer app is usually the simplest. The supply-side app, for drivers, couriers or merchants, carries the harder real-time work: going online and off, receiving and accepting jobs, turn-by-turn flow, earnings visibility, incentives and quests, and support access. Supply-side quality is not a polish concern; it is the retention lever on the side of the market that actually decides liquidity. Drivers multi-home ruthlessly, and the app that respects their time, transparent earnings, fair assignment, fast support, keeps them online more hours.

The third product is operations tooling, and it is the one nobody budgets: a city-team console for supplier onboarding and verification, live market monitoring, incident and refund handling, fraud review, promotion configuration and zone management. Early-stage marketplaces are operations businesses wearing an app; the first two employees after the engineers are city operations people, and they cannot run a market from a database client. Underbuilding this console does not save money; it converts every operational question into an engineering interruption.

Plan capacity accordingly. A realistic version one, all three products on the shared spine, is in the range of six to nine months for a senior team of six to ten: two or three backend engineers on spine and dispatch, two mobile engineers if going native or a smaller crew on a cross-platform stack, one frontend for the ops console, a designer, a product lead and QA. Costed at the offshore and nearshore rates discussed in the software development cost guide, that lands most disciplined version-one builds in the low-to-mid six figures, with the exact number driven far more by scope discipline than by rate cards.

What each of the three products must do at version one

Product	Version-one scope	The mistake to avoid
Consumer app	Request, price, track, pay, rate; history and support entry	Feature-stuffing this app while the other two starve
Supply app	Online state, job offers, navigation flow, earnings, incentives, support	Treating it as a stripped consumer app; it is the retention product
Operations console	Supplier onboarding, live market view, refunds, fraud flags, zones, promos	Running the city from spreadsheets and database queries

The minimum honest scope, product by product. The consumer app is the smallest column, which surprises every first-time founder.

The liquidity math that decides survival

A marketplace clears or it dies, and clearing is measurable. On the demand side the metric is the experience gap: how long a user waits for a match and how often no supply is available at all. On the supply side it is utilization: what share of an online hour is spent earning. The two fight each other, more idle drivers mean shorter pickups but poorer driver economics, and the craft of running a young marketplace is holding both inside tolerable bands in one small geography before spending a single dollar on the next one. This is why launch strategy is zonal: one district saturated beats one city sprinkled, every time.

The cold start runs on subsidies, and the discipline is in their design. Supply-side guarantees, earnings floors for early drivers who stay online in launch zones, buy the availability that makes early consumer experiences good; demand-side discounts buy trial. Both are rented, not owned: the test of the wedge is what remains when the subsidy tapers. Cohort retention at month three, organic order share, and driver hours retained at normal incentive levels are the numbers that say whether a market is forming or being rented, and the ride-hailing economics guide walks the full unit-economics stack underneath them.

Set the take rate to the market's physics, not to the spreadsheet's hopes. Commissions in mobility and delivery commonly land between fifteen and thirty percent, but the number that matters is supplier take-home versus their alternative: price the platform so a committed driver earns visibly more than the informal version of the same work, or supply evaporates at the first competitor promotion. Fare experiments, minimums, and surge policies all propagate through driver earnings, and every pricing decision should be checked against the supply dashboard before it ships.

The three numbers a launch city lives or dies on

Under 8 minutes Pickup or delivery-dispatch time that keeps consumers Illustrative comfort threshold from marketplace practice; past it, users reopen the incumbent behavior.

60 percent plus Share of an online hour a supplier spends earning Illustrative utilization floor for driver economics to beat the informal alternative.

Month three The cohort checkpoint that separates markets from rentals Retention and organic order share once launch subsidies taper tell you if a habit formed.

Payments: the feature that becomes the business

In every super-app story, payments start as plumbing and end as the point. Version one needs to collect money reliably in whatever mix the market uses, cards where they exist, cash where they rule, local wallets where they already won, and needs honest internal accounting: a double-entry ledger recording every fare, commission, incentive, refund and cash-collected balance per driver. Cash markets make the ledger harder and more important, because the platform's money is sitting in driver pockets as float, and reconciliation, collection thresholds and settlement runs are core product, not back office.

The strategic fork arrives with scale: keep riding external payment providers, or become a wallet. The stored-value wallet is the super-app move, it cuts processing costs, holds float, makes cross-service payment frictionless and generates the transaction graph that financial services are later built on, but it is also a regulatory commitment: e-money licensing, KYC obligations, anti-money-laundering programs and capital requirements, varying by market and rarely trivial. The pattern that works is the one the giants ran: partner first, piggyback on a licensed wallet or bank rails while volume grows, and take the license step when transaction volume pays for the compliance apparatus. What makes that step cheap is having built the ledger-with-pluggable-methods architecture on day one.

Design the money path for auditability from the first transaction. Immutable transaction records, idempotent operations, explicit state machines for payment lifecycles, and reconciliation reports that operations staff can actually read: these are unglamorous requirements that decide whether the payments layer can pass the scrutiny that licensing, banking partners and tax authorities will eventually apply. Retrofitting auditability into a fast-and-loose money path is among the most expensive migrations in this category.

The payments maturity ladder, one earned rung at a time

1. 1

   Collect and accountVersion one

   Cards, cash and local wallets through providers, on top of an internal double-entry ledger with per-supplier balances.

2. 2

   Partner walletTraction

   Stored value and in-app balance via a licensed partner. Frictionless cross-service payment without owning the license.

3. 3

   Own the railsScale

   E-money license, KYC and AML programs, float management. Volume now pays for the compliance apparatus.

4. 4

   Financial servicesThe prize

   Driver and merchant lending, insurance, pay-later, underwritten on the platform's own transaction history.

Expansion discipline: when service two actually earns its slot

The second service is a data decision. The signal is in your own warehouse: consumers opening the app at meal times a mobility product does not serve, search terms for services you do not offer, drivers idle in the afternoon lull that a delivery service would fill, merchants asking whether you deliver. Grab added food where mobility had already built both the audience and the courier network; the expansion reused two existing assets and filled a utilization trough. That is the template: the right second service shares your spine, reuses your supply, and fills a measured gap in demand or utilization, and the wrong one, however large its market, shares nothing and restarts the cold-start problem from zero.

Sequence the integration as carefully as the choice. The new service launches inside the existing app, on the existing identity and payment path, with cross-service promotion, ride credits for first food orders, bundled loyalty, doing the acquisition work that paid marketing did the first time. This is the compounding advantage of the super-app structure: each service after the first acquires customers at a marginal cost the standalone competitor cannot match. If the new module is instead shipped as a separate app with a separate account, the spine investment is wasted and the portfolio is just a holding company with a shared logo.

Know what not to build. Services with no spine reuse, no supply reuse and no frequency contribution belong to partners, not to the roadmap: the mature super apps fill their long tail, hotels, flights, ticketing, with partner integrations and mini-app platforms rather than first-party builds. The test for build versus partner is the same asset-reuse logic that picked service two, and the honest answer for most verticals, most of the time, is partner. Bloat is the death mode of super apps that survive the cold start: every added tile taxes the interface, and a home screen of twenty mediocre services loses to two excellent ones.

Expansion calls that compound versus calls that bloat

Do this

• Expand into measured demandYour own data shows the gap: meal-time opens, unserved searches, idle supply in specific hours. The expansion fills numbers, not vibes.
• Reuse at least two assetsSpine plus supply, or spine plus merchants. Asset reuse is what makes service two cheaper than a competitor's service one.
• Launch inside the app, on the walletOne account, one balance, cross-service credits. The compounding acquisition advantage is the point of the structure.
• Partner the long tailHotels, tickets and niche verticals via partners or mini-apps. Their demand, your rails, no cold start.

Not this

• Expanding to enlarge the pitch deckA bigger addressable market on a slide funds nothing. Unearned services split focus and budget across parallel cold starts.
• Building service two on a forkA separate app, account or payment path throws away the spine. That is a portfolio, not a platform.
• Competing with your own partners earlyFirst-party clones of partner services before the data justifies them burn the ecosystem that filled your long tail.
• Confusing tiles with valueTwenty mediocre services lose to two excellent ones. Every tile taxes the interface and the operations team.

The build plan: phases, team and where the money goes

Phase one is the spine and the wedge, six to nine months with the six-to-ten person senior team described earlier: identity, ledger-based payments, generic dispatch, and the three products, consumer app, supply app, operations console, for the single wedge service in a single city. Resist every scope addition that is not required to clear the launch zone; the version-one feature list should embarrass the founder slightly. Phase two is liquidity: three to six months of zone-by-zone operations, subsidy tuning and retention measurement, during which engineering hardens dispatch, builds the experimentation and fraud tooling the live market demands, and resists building service two.

Phase three, expansion, begins when the wedge's cohort numbers hold without heavy subsidy and the warehouse shows measured demand for the adjacent service. Because the spine already exists, service two is a module: typically three to five months to launch inside the app, reusing identity, payments, dispatch and the supply network wherever the vertical allows. Payments maturity advances on its own ladder in parallel, provider, partner wallet, license, each rung justified by transaction volume rather than ambition.

Team shape matters as much as team size, and the scarce profile is marketplace-operations engineering sense: people who have built dispatch, pricing or driver systems before, who know that the ops console is a real product and that the driver app is the retention lever. This is a place where an experienced external team can compress the risk of the first nine months, the shape of engagement we lay out in the dedicated team model, provided the engagement is structured around the spine-and-module architecture rather than a fixed-bid feature list that welds the first vertical into the foundation.

Frequently asked questions

Grab was not built as a super app; it was built as a sequence, one earned service at a time on a spine designed for expansion. For the wedge choice, the architecture and the honest budget, read how to build an app like Grab.