What a Marketplace Launch Actually Needs

A marketplace launch gets described as a technology project and run as an operations one. The platform side is real, but it is bounded and it is somebody’s job. What decides whether you take orders in week one is the sequence underneath it: which areas you serve, which merchants agreed to be there, who typed their catalog in, and who pays them on Friday.

This is that checklist. It follows the order in the launch checklist because the order is load-bearing — an outlet cannot be placed on the map before its zone exists, and a test order proves nothing until a catalog is real.

Two kinds of item appear below, and it is worth separating them:

• Configuration — something the platform already does, that somebody sets in the dashboard. An afternoon, and reversible.
• A product decision — something only you can answer, that the platform will execute either way. Your take rate. Whether you accept cash. Who owns catalog accuracy. Cheap to set, expensive to change once merchants have signed.

Most stalled launches are not blocked on configuration.

1. Structure before merchants

Zones are the geographic foundation: a city, a district, a cluster. Every outlet lives in one, and a customer’s location decides which zone — and therefore which merchants — they see. Draw the boundary generously and serve precisely: the boundary matches customers to a zone, while service areas control where delivery is actually offered and what it costs. Service areas stack in order so the first match wins — how “cheap nearby, more further out” is expressed. Details in Zones.

Business types are your verticals — Food & Restaurants, Retail Stores and Supermarkets are live today, and each outlet belongs to exactly one. They carry their own tags, custom fields and notification settings, and a zone’s service areas are configured per business type, so restaurants and supermarkets in one city can have different coverage without per-outlet micromanagement.

Configuration: drawing zones, enabling verticals, stacking service areas. Decision: how many cities on day one, and how many verticals. One well-covered zone beats three thin ones.

2. Vendor onboarding is a routine, not a project

An outlet is one merchant location. Its record carries a name and machine code, its business type and zone, a map-pinned address, contact details, operating hours and any custom fields you defined on the business type. Get the address right — it drives delivery coverage, distances and driver navigation.

New outlets and new drivers can arrive through public application forms and land in an approvals queue rather than being typed in by hand. Worth using even at ten merchants: it collects the same information every time, and nothing reaches the customer app without your sign-off.

Merchant teams get partner-app access under two roles — outlet owner (full control, including earnings and settlement) and outlet manager (day-to-day orders and availability, without the financial control).

Configuration: the outlet form, the approval queue, the two roles. Decision: what evidence you require before approving, and whether merchants build their own catalogs or you do it for them.

3. Catalog is the part that slips

A restaurant menu is dozens of items with modifiers. A supermarket is a department-structured catalog with thousands of rows. Both are supported, and both need an owner.

The tooling that matters at launch scale is XLSX export and import, with create, update and copy modes — a category-wide price rise becomes a spreadsheet job, and copy mode clones a catalog between outlets. One caution the docs state plainly and it is worth repeating: update mode overwrites what it matches, so export before any bulk import. Beyond that, per-outlet menus, per-channel price books, and sold-out that re-enables itself at a time the merchant picks. See Catalog builder.

Decision: who owns accuracy. A customer who orders four things and receives two does not order a fifth, and no import mode fixes that.

4. Payments, and the money you never touch

Connect an online gateway — Stripe is the primary option with Apple Pay and Google Pay included, alongside Finix, Paytrail, InterGateway and Banca Transilvania; your account team sets up anything beyond Stripe. Then enable the physical methods you actually support: cash, card on delivery, card terminal, bank transfer.

Each method is configured rather than merely switched on: a customer-facing name, a priority that fixes its position in the checkout list, conditions restricting it by business type, zone or outlet, and optional minimums, maximums and operating hours. Commission is set up as outlet earnings rules with priorities; where several could apply, the highest priority wins.

Run one small real payment end to end before launch. It is the single most common source of go-live surprises.

5. Dispatch

Three shapes: your own fleet, a delivery network (DoorDash Drive, Uber Direct, Shipday, Nash), or a mix — own fleet for core hours, network for overflow. Whichever you pick, set each outlet’s preparation time, because it drives both the time the customer is quoted and the moment a driver is called.

Assignment is manual from the dispatcher panel, automatic via auto-dispatch, or both — automation for volume, humans for exceptions. Dispatch is its own role: a dispatch manager signing in gets Orders and the Dispatcher panel and nothing else.

6. Payouts are a ledger, not a bank

This is the item most often discovered late. A running balance is tracked for every outlet and every driver: an online-paid order leaves you holding money owed to the merchant, a counter cash order leaves the merchant holding your share, and cash on delivery nets against what you owe the driver. 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 bank transfer or hand over the cash, then record it — and every entry becomes a settlement transaction with a date, an amount and a recipient, which is what your finance process needs at year end. Merchants and drivers see the same balance in the partner app, so keeping the record in step with the bank is not optional. Settlements has the weekly and monthly routine.

7. Support, before you need it

Access is role-based throughout, and the money permissions are set separately from the rest: edit an order, add a fee, collect payment, process a refund, cancel, waive a cancellation fee — each granted per role. A common shape is everyone can edit, only managers refund. Register staff are a separate roster with their own PINs, because a register signs in as a person per shift rather than as an account with a password.

One login per person, and deactivate leavers the same day: shared accounts make till sessions, refunds and approvals unattributable.

Decision: who answers the phone at 8pm on a Saturday. Contact-form submissions land in the dashboard and go stale fast.

8. The app stores

Your apps publish under your developer accounts, your name and your domain — a store requirement, not a branding preference. Apple’s App Review Guideline 4.2.6 rejects apps created from a commercialised template or app generation service “unless they are submitted directly by the provider of the app’s content.”

The one-time deployment package covers both store submissions, the custom domain and SSL, branding, payment integration, catalog setup, staff training and go-live support, and the platform side runs in 5–7 days. Store review is its own clock; start the developer accounts early.

9. The test order

Before go-live, run a full order through every flow you plan to offer: place it from the customer app, accept and progress it as the merchant, assign a driver, check the notifications landed, test a refund and an edit, and confirm the order appears in reports. Use the real outlets, zones and payment methods you are launching with — an order through a placeholder outlet proves very little.

Then switch your launch outlets live, confirm none is left paused, and watch the first day in reports.

The short version

Structure, then supply, then catalog, then money, then dispatch, then a real order. The platform work has a known shape and a known duration; the merchant list, the catalog owner and the payout routine are yours, and they are what the launch date depends on.

Want to walk your own sequence against a live platform? Book a demo.