A logistics marketplace expanding city by city must decide what is centralised and what is local. How should that be structured?

The structure

Centralise the platform, localise the parameters.

• Centralised: the matching engine, pricing engine, order state machine, payments, the driver and customer applications, data platform, and every piece of infrastructure. One codebase, one deployment, one on-call.
• Localised as configuration: pricing coefficients, service area boundaries, vehicle types, operating hours, surge parameters, compliance requirements, supported payment methods, language.
• Localised as operations: supply acquisition, driver support, partnerships, regulatory relationships — which are human activities and genuinely local.

Why this split

A new city should be a configuration change, not a project. If launching a city requires engineering work, expansion speed is bounded by engineering capacity, which becomes the constraint on the business's growth.

The test is concrete: how long from decision to first order in a new city, and how much of that is engineering? A mature platform answers "days, and none".

What makes it hard

• The second city reveals what varies, and it is never what was predicted. The parameters that must be local are discovered, which is why building an elaborate configuration system before the second city produces flexibility along the wrong axes.
• Genuinely different market structures occasionally require more than configuration — a city where the vehicle mix, regulation or customer behaviour differs fundamentally. The discipline is to resist forking: one fork becomes two, and then the platform is several products.
• Data model implications. City must be a first-class dimension from the first row of data, because retrofitting a partition key into a live schema is one of the genuinely painful migrations.

The organisational half

A city operations team that can adjust local parameters without engineering is what makes the model work. If every parameter change is a deployment, the central team becomes a queue and cities work around it.

That requires the configuration to be safe to change — validated, bounded, auditable and reversible — which is real engineering work and is what makes the difference between a configurable platform and a dangerous one.