By business model
Five shapes cover almost every operator we deploy for. Each one turns on a different part of the engine.
Single restaurant
Single brand, multi-location
Multi-vendor marketplace
Fleet operator / mobility network
Enterprise & logistics
By situation
Most buyers arrive with a constraint rather than a model. Pick the one that sounds like your quarter.
First platform, one city, one vertical
You have the demand and the restaurants but no software. The fastest path is a standard configuration on your brand, live in one city, with the parts you will need later switched off rather than missing.
Migration without stopping trading
An existing platform — custom, inherited, or bought — is now the constraint. The work is moving data and habits across while orders keep landing.
Own the customer and the margin
You are trading through third-party marketplaces and paying 18–30% for a customer you never see. Your own channel does not replace them on day one — it takes the repeat orders back.
Grocery beside food, rides beside courier
You already run one vertical successfully and the same fleet, customers, and city can carry another. Nothing is rebuilt — a second vertical is configuration on the engine you already operate.
Gateways, compliance, and data residency
The operation works and the next market has different payment rails, different obligations, and often a different language. The platform is deployed per market rather than stretched across them.
Whichever route you take, deployment is four steps
Two to four weeks for a standard configuration. Custom connectors and extra verticals extend step three, not the whole plan.
Choosing a Route
Migration, mixed models, and what happens when the business changes shape.
Not sure which applies? Describe your operation
What if we are two models at once? +
Common — a brand with its own restaurants that also lists third-party vendors, or a delivery operator that also runs rides. Both run on one instance. Vendor onboarding, commission, and dispatch rules are configured per group rather than per platform, so one operation can carry two models without two deployments.
Can we start on one model and move to another? +
Yes, and most operators do. A single-restaurant deployment that grows into a marketplace turns on vendor onboarding, commission rules, and the vendor panel. It is a configuration change with a data migration for existing orders, not a new build.
Does a faster launch mean a cut-down product? +
No. The two-to-four-week configuration ships all the apps and the full engine. What is deferred is custom connectors, additional verticals, and additional cities — each of which is added after trading starts without touching what is live.
How do you handle migration from our current system? +
We import vendors, catalogue, customers, and open orders, then run both systems in parallel while configuration is verified. Cutover happens per city or per vendor group. The sequence is designed so trading never stops, which is why migration deployments run four to eight weeks rather than two.
What does pricing depend on? +
The model, the number of verticals and cities, and whether you need connectors outside the twenty-four that ship configured. Ownership, branding, the API, and compliance configuration are not tiered — they are in every deployment. Pricing is quoted against the configuration spec from step one.
Tell Us How You Trade Today
Restaurants, cities, order volume, who delivers, and what you run now. We'll map it to a model, a configuration, and a timeline before you spend anything.