Launching a Regional Aggregator City by City

A regional aggregator is sold to investors as a map and run as a sequence of city launches. The map is the easy part. What decides whether city three works is whether cities one and two produced a routine — a merchant-onboarding rhythm, a dispatch configuration that holds, a payout cadence nobody has to think about — or whether each one was improvised.

This is the sequence, and the order is deliberate. Every step below is something you finish in one city before starting the next.

Supply first, and it is not close

The single most common failure in a regional launch is opening a city because the map says it is next, rather than because a merchant list exists.

A customer who opens your app in a new city and finds four restaurants does not come back to check whether you added more. There is no second first impression, and paid acquisition into thin supply is the most expensive way to discover that. So the launch date is not a date — it is a threshold: a merchant count and a category spread you decide in advance and refuse to launch below.

The mechanics that make this repeatable are in Outlets, and the useful pattern is a standing routine rather than a project: profile, approval, payments, service area, catalog, test order. Merchants can apply through a public form and land in an approvals queue, so the same information is collected every time and nothing reaches the customer app without your sign-off. Onboard in batches, and insist on the test order — an outlet that has never processed one discovers its problems on a real customer.

Two details that quietly decide the first week: get the map-pinned address right, because it drives coverage, distances and driver navigation, and keep operating hours honest. Outlets that show open and do not respond are the fastest way to lose a new customer.

Draw the zone generously, serve precisely

A zone is the geographic unit of a city launch, and adding a city is a matter of creating a zone and onboarding outlets into it rather than re-architecting anything. Two rules pay for themselves immediately.

The boundary and the coverage are different things. The zone boundary decides which customers are matched to the city — which merchants, settings and content they see. Service areas decide where delivery is actually offered and what it costs, and they can be narrower. The common shape is a boundary covering the whole city with tighter service areas underneath, stacked in order so the first match wins, which is how “cheap nearby, more further out” gets expressed without a second zone.

Do not overlap zone boundaries. Every location should resolve to exactly one city, or the customer experience stops being predictable and your reports stop being comparable.

A customer outside every zone is told you do not serve their area yet. That is a better outcome than a broken storefront, and it is also a demand signal — the addresses people try are the cheapest evidence you will get about which city is genuinely next. Details in Zones.

Configure verticals once, reuse them per city

Your business types — Food & Restaurants, Retail Stores, Supermarkets — are configured at the marketplace level, with their own tags, custom fields, notification settings and operating rules. Each new zone inherits them, and each zone’s service areas are set per business type, so a supermarket and a restaurant in the same new city can have different delivery coverage without anyone editing outlets one by one.

That is the leverage in a city-by-city model: by city three, the only genuinely new work is a boundary, a merchant list and a driver roster. The vertical configuration, the notification templates, the commission rules and the reports are already built.

Dispatch radius: start tight, widen on evidence

Dispatch settings do not transfer between cities as cleanly as configuration does, because geography does not.

Start each city conservatively. Dispatch radius is set globally or per driver group, and a driver group is also where vehicle types, the zones and business types the group covers, and the group’s pay rules live — so a new city’s cyclists and its suburban car drivers are two groups, not twenty individual records. Auto-dispatch can be overridden per outlet, on or off, regardless of your global setting, which is how you pilot it on one merchant before trusting it with a city.

Where your own fleet does not yet exist, a delivery network covers the gap. Two settings decide when: precedence — network first or your own drivers first — and priority order between networks. Network-first suits a city with no drivers yet; flip it once your own fleet is real. Leave cost comparison off until your in-house delivery costs are actually known, because before that it compares a real quote against a guess.

Payouts before volume, not after

A running balance is tracked for every merchant and every driver, and it moves in four ways: an online-paid order leaves you holding money owed to the merchant, a counter cash order leaves the merchant holding your share, cash on delivery nets against what you owe the driver, and driver earnings accrue on top. The result is one net number per party, which can run either way.

The platform records payouts; it does not move money. You make the transfer, then record it — and merchants and drivers see that recorded balance in the partner app, so a record that drifts from the bank is the fastest way to lose their trust in a city you have just opened.

The routine that scales, from Settlements: weekly, review driver balances and run the bulk payout; weekly, scan merchant balances for anything drifting the wrong way — a merchant accumulating uncollected cash is a conversation, not a spreadsheet problem; monthly, reconcile settlement transactions against your bank and your gateway’s own payouts. Check pending refunds before any payout run, so you are not settling money that is about to go back to a customer.

Establish this in city one, when it takes twenty minutes. In city four it is the thing that breaks first.

What to measure before opening the next city

Gross order volume is the number everyone watches and the one that tells you least — it mostly reflects what you spent. Five better questions, each answerable from the dashboard:

1. Are customers coming back? The platform computes customer segments automatically — repeat, active, at-risk, lapsed. A city with rising orders and a growing lapsed segment is buying orders, not building a market.
2. Can you assign a driver at peak? Auto-Dispatch Analytics gives time-to-assign and failed searches. Rising time-to-assign at peak is usually a supply problem rather than a settings one, and it will not fix itself in the next city either.
3. Where is coverage thin? If one part of the zone repeatedly shows orders waiting and no nearby drivers, that is a recruitment signal on a map.
4. Are merchants healthy? Per-outlet reporting shows the ones struggling before they churn, which is much cheaper than replacing them.
5. Is the ledger clean? Balances reconciled, no drift, no uncollected cash piling up.

Reports share one date range with a maximum span of 366 days, filter by zone and business type, and export to CSV with personal data masked — so “city one versus city two, same window” is a genuine comparison rather than an argument. See Reports.

Then do it again

City two is the test of whether city one produced a routine. If the answer to “who onboards the merchants, who trains them, who runs the payout, who watches dispatch in week one” is the same set of names and the same steps as last time, the model works and the map is now just a queue.

If it is improvised again, the honest move is to fix the routine before adding geography — because every unresolved habit gets multiplied by the number of cities you open.

Planning a regional rollout? Book a demo and we will walk the sequence against your own map.