A services marketplace launches in one city with one category. Three years later it runs dozens of categories across many cities with different pricing and compliance rules. What should have been built on day one, and what should deliberately not have been?

What to build on day one

Not the multi-city, multi-category platform — you cannot know the shape of variation before you have seen it, and a generic system built from imagination is generic in the wrong dimensions. What you build is the ability to find out cheaply:

• A seam where variation is certain. Pricing, availability rules and compliance will vary — that much is knowable. Putting them behind an interface costs almost nothing on day one and is the difference between a configuration change and a rewrite in year three.
• City and category as first-class identifiers from the first row of data. Retrofitting a partition key into a live schema is one of the genuinely painful migrations, and adding a column nobody reads yet is free.
• Observability that can answer questions you have not thought of, which mostly means structured events with enough dimensions to slice by.

What not to build

A rules engine, a workflow engine, a plugin system, or a multi-tenant abstraction — any of the machinery whose purpose is to handle variation you have not yet observed. Generic mechanisms built before the second instance encode the first instance's assumptions in a form that is harder to change than a hard-coded version.

The reliable heuristic is the rule of three: hard-code the first, copy for the second, abstract at the third — because only at the third do you know which parts actually vary.

The judgement being tested

Evolutionary architecture is not "defer everything". It is knowing which decisions are cheap to reverse later (a service split, a caching layer, a queue) and which are expensive (a data model, a partition key, an identity scheme, a public API contract). Spend design effort on the second category and let the first be discovered. Getting this backwards — agonising over the service boundary while accepting a schema that cannot express the second city — is the most common expensive mistake in a fast-growing marketplace.