How to use this guide

This guide answers one question: how do you build the smallest marketplace that works correctly today, without making the handful of decisions that force you to rewrite half of it a year from now.

Who it is for#

For a founder, product owner or developer planning an MVP, a small or a mid-sized marketplace that one person or a small team can build and keep running. The assumed order of magnitude is tens of sellers and a few thousand products, not millions of listings and a warehouse network.

The marketplace here may be a standalone platform with its own catalogue and checkout, an existing store extended with third-party sellers, or a platform whose sellers already run their own shops and want to connect a catalogue or stock levels.

What is not here#

Nor is it architecture written for a scale you do not have. Distributed designs, custom payment processing, elaborate fraud systems and multi-warehouse logistics appear only to explain why they are out of scope, or which concrete trigger would justify thinking about them.

Chapter structure#

Every chapter keeps the same order so it can be read selectively:

• the problem in business terms rather than technical ones;
• the minimum version, meaning the smallest implementation that is correct and operable;
• what not to build at this stage;
• what to plan ahead, because it is expensive to retrofit;
• triggers after which the current version stops being enough;
• the next stage, always incremental;
• common mistakes and a checklist.

Vocabulary#

These terms recur in every chapter and mean exactly what follows.

How recommendations are judged#

Before this guide recommends building anything, it goes through seven questions:

1. Does the marketplace need this to operate correctly right now?
2. Is this mainly required at a larger scale?
3. Can an external provider own this responsibility?
4. Can the process stay manual to begin with?
5. Does skipping it today mean an expensive migration later?
6. Can the extension path be preserved by a small data-model decision instead of the full feature?
7. Does the recommendation follow from experience or a clearly stated principle rather than habit?

Relation to the compliance guide#

This guide does not repeat legal obligations. Where a topic touches EU market requirements, it covers only what follows for the data model and the flow, and points to the other track reachable from the same index.

The split is simple: operator obligations answer "what do I have to meet", this guide answers "how do I model it so meeting it does not require rewriting the system".