Launch in 2–4 weeks
A standard configuration on your brand, live in one city, with the parts you will need later switched off rather than missing.
Replace a legacy build
Moving data, integrations, and habits across while orders keep landing — cutover per city or per vendor group rather than all at once.
Get off aggregators
Your own channel does not replace third-party marketplaces on day one. It takes the repeat orders back, which is where the margin is.
Add a vertical
The same fleet, customers, and city carrying a second vertical. Configuration on the engine you already operate, not a second build.
Enter a new country
The platform is deployed per market rather than stretched across them — local gateways, local residency, local compliance.
You have the demand and the restaurants but no software, and usually a date that is not moving — a season, a lease, an investor milestone. The fastest path is a standard configuration with no custom work in the first release.
A custom build, an inherited system, or a bought platform is now the constraint: changes take months, the vendor is gone, or the hosting bill no longer makes sense. The hard part is not the new platform, it is leaving the old one without stopping trading.
You trade through aggregators and pay a commission you cannot negotiate on a customer whose details you never receive. The realistic goal is not switching them off — it is moving repeat customers to a channel you own while discovery stays where it is.
One vertical works and the operation has spare capacity — riders idle between meal peaks, a customer base that orders more than food. A second vertical uses the same dispatch, the same wallet, and the same settlement run.
The operation works and the next market has different payment rails, different data obligations, and often a different script. Each market gets its own instance so a regulator, a gateway, or an outage in one never reaches another.
How the five compare on time
Same four-step deployment in every case. What stretches is the step where data, accounts, or approvals sit outside our control.
Situation Questions
Deadlines, parallel running, and what happens when more than one situation applies at once.
Not sure which fits? Describe your operation
What if two situations apply at once? +
Common — replacing a legacy build while also entering a new country, or adding a vertical during an aggregator exit. The sequences merge rather than run back to back: the migration work and the localisation work happen in the same configuration window, and the timeline lands near the longer of the two rather than their sum.
Can you hit a fixed launch date? +
Usually, provided the date is at least the standard window away and the items outside our control start immediately. App store review and payment gateway approval are the two that can move a date, and both depend on documents from you rather than work from us.
Does parallel running cost extra? +
It is part of a migration deployment rather than an add-on. Both systems trade at once until each city or vendor group is verified on the new configuration — you keep paying your existing vendor for that period, which is the real cost and the reason cutover is phased rather than slow.
Can we launch in one city and expand later? +
That is the default. One city, one vertical, one gateway at launch; additional cities and verticals are configuration added after trading starts without touching what is live. Each additional city is typically days rather than weeks.
What do you need from us to start? +
For scoping: your current rules — commission, delivery fees, zones, and who delivers. For build: brand assets, catalogue, and gateway account details. For launch: an operations team available for training and a date. Nothing else blocks the first three days.
Tell Us What's Forcing the Timeline
Restaurants, cities, order volume, who delivers, and what you run now. We'll map it to a sequence and a launch date before you spend anything.