Guide chapters
00 - How to use this guide01 - The marketplace model comes before features02 - Sellers: data model and onboarding03 - The seller catalogue04 - Integrating seller shops05 - Stock levels06 - Cart and checkout07 - The order model08 - Shipping and fulfilment09 - Payments10 - Payouts11 - Commissions12 - Promotions and loyalty13 - Returns and disputes14 - Moderation and operator decisions15 - The operator panel: from one person to a team16 - Events, notifications and recovery17 - Security boundaries in a marketplace18 - Reversible and irreversible decisions19 - The maturity matrix: manual or automated20 - A reference MVP
Chapter 20
A reference MVP
Assumptions#
The example below ties the whole guide into one coherent picture. It is not the only valid architecture, only one that under these assumptions will not need rewriting for the next few years.
- tens of sellers, a few thousand products;
- shipping handled by the seller;
- a cart may contain goods from several sellers;
- the operator is one person, sometimes two;
- selling to consumers in the EU.
What is built#
| Area | Scope in the MVP |
|---|---|
| Seller | account states, onboarding with computed readiness, anonymisation separate from deletion |
| Catalogue | product on the seller, variants, moderation, room for an external identifier |
| Stock | quantity and reservation on variant and location, changes as atomic operations |
| Cart | the line knows its seller, grouping, shipping on the group |
| Checkout | value snapshot, validation in one place, payment and order kept apart |
| Order | line with a seller and its own state, cancellation and returns per item |
| Money | split recorded at capture, commission persisted on the line, payouts linked to orders |
| Returns | request with items, running totals, a way back after a payout |
| Panel | contextual screens, isolation in the access layer, a decision author field |
| Recovery | operation identifier, visible failed jobs, an event ledger |
What is delegated#
- payment processing and seller identity verification;
- transactional message delivery;
- file storage;
- product search, once the catalogue outgrows the database.
What stays manual#
- seller approval;
- report moderation;
- payouts;
- entering tracking numbers;
- reviewing discrepancies between your record and provider data.
What is deliberately deferred#
| Deferred | The trigger that changes it |
|---|---|
| Continuous sync with external shops | the same goods selling in two channels |
| A payout schedule | repetition and the first mistake |
| A hierarchy of commission rules | the first individually negotiated rate |
| A loyalty programme | a deliberate decision about platform funding |
| Queues and roles in the panel | a second person making decisions |
| Carrier integration | parcel volume producing errors |
| Warehouse processes | a real need to run several dispatch points |
| A central staff activity log | accountability between several people |
What actually makes this scale#
Not the number of features, but four data-shape decisions that ran through the whole guide.
- Ownership at line level, not order level.
- Persisting money values at the time of the event rather than computing on read.
- A separate identifier for the outside world.
- The ability to establish and repair the state of a partly successful operation.
What this example does not settle#
The business model, the product categories, the market and who is party to the sale change some of the answers above. The guide shows which decisions have to be made and what each one costs, not which one is right for your case.
The regulatory obligations you have to meet under these assumptions are covered by the other track, reachable from the same index.
Need to implement these processes in a real marketplace?
I design multi-vendor platforms with onboarding, payments, moderation, and operational workflows.
Explore marketplace development