Marketplaces look simple from the outside. There are two sides, a transaction and a fee. From the inside they are among the hardest products to shape, and most go wrong before any code exists. The homepage turns into a search bar, supply turns into a feed, and the platform ends up competing with a search engine it cannot beat. This report covers the shape that holds up and the six layers under it.
The six-layer model
A requester asks one question and gets a handful of matches back. Trust and money decide whether the deal stays on the platform, and a person runs all of it while the marketplace is young.
- Layer 01Request flowFour to seven questions only you can match on.
Broken whenThe homepage is a search box, or the request form is mostly free text.
- Layer 02MatchingA few curated matches, never a feed.
Broken whenRequesters scroll a list, then leave to compare somewhere else.
- Layer 03Two dashboardsDemand side and supply side are different products.
Broken whenOne dashboard tries to serve both sides and neither side opens it.
- Layer 04Trust signalsReply time, response rate, a named operator, reviews.
Broken whenRequesters email to ask whether the platform is real before they submit.
- Layer 05MonetizationLead credits, take rate or subscription.
Broken whenSuppliers move deals off the platform to avoid the fee.
- Layer 06Operator consoleThe human in the loop.
Broken whenThe team runs the marketplace from five tools and a shared inbox.
Layer 01Request flow
The question the demand side fills in. Four to seven structured fields that only your marketplace can act on, with free text as an escape hatch, not the main signal. The shape of that question is what makes the platform worth using instead of a search engine.
Layer 02Matching
The logic that turns a request into a short list. In the early months a person does it; later an algorithm proposes and a person corrects. Either way the output is a few tailored proposals, returned within a time the platform commits to.
Layer 06Operator console
Open requests, suppliers who have not replied, escalations, refunds, manual overrides. In the first weeks of a marketplace this console is the product. Anything you plan to automate, you should be willing to do by hand first.
Money and trust
How money flows decides who the platform works for. There are three common shapes, and most curated marketplaces start with the first.
- Lead credits. Suppliers pay per vetted request. Predictable for them, and the platform only earns when it delivers a real lead.
- Take rate. A share of each completed transaction. It aligns well once both sides depend on the platform. Too early, and suppliers take the deal off-platform to avoid the cut.
- Subscription. A flat monthly fee. Predictable, weakly aligned, better as a premium tier than as the main model.
Trust is the reason someone submits a request instead of searching one more time. In our work the signals that matter most are about time and people: a displayed reply time, a response-rate badge that is hard to fake, and a named person behind the matching. Reviews matter too, but a supplier with three completed jobs has reviews that are mostly noise, so gate public ratings until there is enough history to read.
Three scales, one table
The six layers hold from the first curated match to several regions. What changes is who does the matching and how much of the trust layer is public.
| Layer | Curated, early stageScale 01 | Liquid, scale stageScale 02 | Multi-regionScale 03 |
|---|---|---|---|
| Request flow | Four to seven structured questions | The same, plus follow-up questions by request type | A question set, currency and language per region |
| Matching | A person curates every match | An algorithm proposes, a person overrides | A pool per region, cross-region when allowed |
| Dashboards | Minimal on both sides | Full products on both sides | Branding per region on shared infrastructure |
| Trust | Named operator and reply time on every match | Reviews, response and completion rates, badges | Rating norms and badges per region |
| Monetization | Lead credits or a flat fee per match | Lead credits plus a take rate | Pricing and payouts per region |
| Operator console | Open requests, notifications, escalations | Exceptions, curation, abuse handling | Regional teams plus a global admin |
| Cost band | CHF 15,000 to 25,000 | Up to CHF 45,000 | Scoped per region after a pilot |
| Build time | A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements. | A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements. | Scoped per region after a pilot |
| Live example | Dreilokale (live) | None yet | None yet |
Marketplace stack at three scales
Scale 01Curated, early stage
- Request flow
- Four to seven structured questions
- Matching
- A person curates every match
- Dashboards
- Minimal on both sides
- Trust
- Named operator and reply time on every match
- Monetization
- Lead credits or a flat fee per match
- Operator console
- Open requests, notifications, escalations
- Cost band
- CHF 15,000 to 25,000
- Build time
- A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements.
- Live example
- Dreilokale (live)
Scale 02Liquid, scale stage
- Request flow
- The same, plus follow-up questions by request type
- Matching
- An algorithm proposes, a person overrides
- Dashboards
- Full products on both sides
- Trust
- Reviews, response and completion rates, badges
- Monetization
- Lead credits plus a take rate
- Operator console
- Exceptions, curation, abuse handling
- Cost band
- Up to CHF 45,000
- Build time
- A focused MVP can be ready in two weeks. A scoped product can launch in around two months. We agree the timeline after reviewing your requirements.
- Live example
- None yet
Scale 03Multi-region
- Request flow
- A question set, currency and language per region
- Matching
- A pool per region, cross-region when allowed
- Dashboards
- Branding per region on shared infrastructure
- Trust
- Rating norms and badges per region
- Monetization
- Pricing and payouts per region
- Operator console
- Regional teams plus a global admin
- Cost band
- Scoped per region after a pilot
- Build time
- Scoped per region after a pilot
- Live example
- None yet
What not to build
Most of these come from playbooks written for marketplaces with years of liquidity behind them. At launch they cost more than they return.
- An endless scroll of supply. Once supply is a list, the platform is a directory competing with search. Curate instead.
- Custom messaging in the first version. Email with reply-to routing carries the early transactions. A messaging product is weeks of work that adds little before there is volume.
- Public ratings before there is history. A few early ratings hurt more than they help. Show them once a supplier has enough completed transactions.
- Algorithmic matching at launch. A person matching by hand ships sooner, matches better, and teaches you what the algorithm should do later.
- Native apps before the web works. A responsive web app carries a B2B marketplace until usage proves you need more.
- Several regions at launch. Run one region end to end before you add a second.
Dreilokale
Scale 01 · LiveDreilokale, Switzerland
Dreilokale is a Swiss platform that matches event organisers with locations. It has not launched yet. The founders had the brief and no team, and we built the platform end to end: the matching engine, the CRM, the CMS and the email automation. No AI workflow runs in production there.
An organiser sends one structured request instead of browsing a catalogue, and matched locations reply with tailored proposals, designed to arrive within 48 hours. Organisers and locations each get their own dashboard. Seen from the venue side, Dreilokale is scale 03 in the Hospitality Stack Report.
Self-audit
Twelve questions for the marketplace you run or are about to build. The score updates as you tick; what the bands mean is explained once on the stacks index.
Method and pricing
The layer model, how to read the cost bands, the notes on Swiss and EU data protection, languages and payment rails, and how these reports are versioned are shared across all five stack reports: how we write the stack reports. The long-form field notes on marketplace design and trust signals go further on single layers.