Marketplaces look simple from the outside, two sides, a transaction, a take rate. From the inside they are one of the hardest products to design. Most fail at the shape stage, long before any code is written: the homepage becomes a search bar, supply becomes a scroll, the demand side compares the platform to Google, and the platform loses that comparison every single morning. This report is the reference for the shape that actually works, a structured request, a curated match, two dashboards, real trust signals, and a monetization layer that aligns both sides.

The six-layer marketplace stack.

Every production marketplace Morvion has audited or built ships the same six layers. The architecture differs by scale; the layers do not.

Layer 01 · Request flow.

The shape of the question the demand side fills in. Four to seven structured questions only your marketplace can act on. Free-text fields are escape hatches, not the primary signal. The request shape is the platform's competitive moat, the question you ask is what makes you not-Google.

Layer 02 · Matching engine.

The logic that turns a request into a small handful of curated supply matches. Operator-driven in early stages, algorithmic at scale, almost always a hybrid in practice. The output is never an infinite feed; it is 3–10 tailored proposals back to the requester within a committed SLA (typically 24–48 hours).

Layer 03 · Two role-scoped dashboards.

The demand-side and supply-side dashboards are different products with different vocabularies, different success metrics, and different cadences. Trying to unify them is a politeness that costs both sides. The requester sees their open requests, the proposals they've received, the conversation around each. The supplier sees inbound matches, proposal templates, response-rate metrics, calendar.

Layer 04 · Trust signals.

The reason people click “request” instead of searching Google one more time. Reviews are the obvious one; less obvious are response-rate badges, named-operator pages, displayed reply times, completion-rate metrics, and the small detail that you reply in under an hour when others reply in three. Trust signals must land in the first viewport.

Layer 05 · Monetization.

Three common shapes: lead credits (supply pays per vetted request, predictable cost), take rate (percentage of GMV, aligns at scale, creates wrong incentives early), and subscriptions (predictable for the operator, less aligned with success). Most live marketplaces start with lead credits and graduate to a take rate once both sides would lose something real by leaving.

Layer 06 · Operator console.

The human-in-the-loop surface for the platform team. Open requests, suppliers notified, suppliers not responding, escalations, refunds, manual overrides. The operator console is the actual product in week one of every marketplace, everything you eventually automate, you should be willing to do by hand first.

“If your homepage is a search bar, you've already lost the differentiation argument.”

Reference architectures · three scales.

Reference 01 · Early-stage curated marketplace.

10–200 supply-side accounts, operator-curated matching, human-in-the-loop on every request. The platform team is the matching engine. The dashboards are minimal; the operator console is the real product. Lead credits or flat per-match fees keep the economics simple.

Request flow ────── 4–7 questions, structured
Matching ──────── operator-curated, 3–10 proposals back in 24–48h
Dashboards ────── requester-side minimal · supply-side minimal
Trust ─────────── named operator + reply time on every match
Monetization ──── lead credits or flat per-match fee
Operator console open requests, notification queue, escalations
Cost band ─────── €60–140k build, €1.5–4k/month run
Build time ────── 12–18 weeks
Live example ──── Dreilokale (Reference 01 → Reference 02 transition)

Reference 02 · Scale-stage liquid marketplace.

200–2,000 supply, algorithmic + operator-overridden matching, public ratings, response-rate badges, programmatic notifications. The matching engine is now real software; the operator console is for exceptions and curation. Take rate may replace lead credits.

Request flow ────── 4–7 questions + dynamic follow-ups
Matching ──────── algorithmic + operator override, < 24h SLA
Dashboards ────── requester-side rich · supply-side rich
Trust ─────────── reviews, response rate, completion rate, badges
Monetization ──── lead credits + take rate (5–15% typical)
Operator console exception handling, curation, anti-abuse
Cost band ─────── €120–280k build, €4–12k/month run
Build time ────── 16–28 weeks
Pattern note ──── Reference 01 graduates here by month 9–12

Reference 03 · Multi-region marketplace.

Multiple jurisdictions, currencies, languages, regulatory regimes. Same six layers, with extra boundary work: per-region matching pools, per-region payment rails, per-region trust signals (a 5-star review in one country isn't equivalent to one in another), per-region operator team. The platform is now several marketplaces sharing one codebase.

Request flow ────── per-region question set + currency + language
Matching ──────── per-region pool, cross-region fallback when allowed
Dashboards ────── per-region branding, shared infrastructure
Trust ─────────── per-region rating norms, per-region badges
Monetization ──── per-region pricing, currency-aware payouts
Operator console regional teams + global admin
Cost band ─────── €220–500k build, €12–30k/month run
Build time ────── 24–40 weeks
Pattern ─────── pilot one region end-to-end, then onboard regions
                  in 4-week passes
From the studio

Morvion built Dreilokale end-to-end as a Reference-01 marketplace currently graduating into Reference-02 territory. The request flow, matching engine, dashboard shapes, and operator console detailed in this report are the production patterns from that build.

Monetization patterns, deeper look.

The single biggest design decision in a marketplace is how money flows. Three patterns ship in production; each one creates a different alignment between the platform, the supply side, and the demand side.

  • Lead credits. Supply pays per vetted request they receive (typically €5–50 depending on margin). Predictable for supply, aligned early (the platform only earns when it delivers a real lead). Best for early-stage and curated marketplaces. Dreilokale runs on this shape today.
  • Take rate. The platform takes a percentage of completed-transaction GMV (typically 5–15% in B2B, 15–30% in consumer). Aligned at scale once liquidity is real; creates the wrong incentives early because supply will route the deal off-platform to avoid the cut.
  • Subscription. Supply pays a flat monthly fee for access. Predictable revenue for the platform, less aligned with supply success. Works as an add-on tier (premium listings, advanced analytics); rarely works as the primary model.

Trust signals, deeper look.

Trust is the conversion lever. The signals that move the needle most, in rough order:

  1. Displayed reply time. “Replies in under 1 hour” on the supplier card outperforms star ratings on click-through-to-request rate. The requester is making a time bet, not a quality bet.
  2. Named operator on the platform side. A real photo and a real name behind the matching engine. The requester knows there is a human, not a spam-trap.
  3. Response-rate badges. “Responds to 95% of requests within 24 hours”, public, hard to fake, predictive of completion.
  4. Completion-rate metrics. “14 successful events in the last 90 days”, recency-weighted because old reviews drift.
  5. Reviews. Necessary but not sufficient. Below 50 transactions, reviews are noise; above 50, they start to predict.

Cost bands · what to expect.

Public ranges from Morvion engagements in 2026, all-in (design + engineering + launch), excluding third-party subscription tools (payments, email, identity, search).

Discovery Sprint ──────── €18–25k · 2 weeks · validates request shape
Early-stage curated ───── €60–140k · 12–18 weeks
Scale-stage liquid ────── €120–280k · 16–28 weeks
Multi-region ──────────── €220–500k · 24–40 weeks
Retainer (post-launch) ── €5–22k/month · matching tuning + ops layer
Per-region onboarding ─── €40–100k after platform ships

The 12-question self-audit scorecard.

For an operator to assess their current marketplace shape. One point per affirmative answer; max 12. Below 6 = a Discovery Sprint will surface faster wins than another feature. Below 4 = the platform is a listing site with extra steps.

  1. Is the homepage a structured request flow, not a search bar?
  2. Does the request shape ask 4–7 questions only your platform can match on?
  3. Does the requester get tailored proposals back within a stated SLA (24–48h)?
  4. Are the demand-side and supply-side dashboards different products?
  5. Do trust signals (reply time, response rate, named operator) land in the first viewport?
  6. Is the monetization model aligned with the current liquidity stage (lead credits early, take rate at scale)?
  7. Does the operator console support a human-in-the-loop for every match in early stages?
  8. Is there a measurable response-time SLA published on the supply side?
  9. Are reviews + completion-rate weighted by recency, not lifetime average?
  10. Does the matching engine have an operator-override path for exceptions?
  11. Is the request → match → transaction funnel instrumented end-to-end?
  12. Can the operator team run the marketplace from one console, not five?

What not to build.

The mistakes we see most often. Skip these even when the playbook says otherwise.

  • The infinite scroll of supply. Once supply is scrollable the platform competes with Google search and loses. Curate, don't list.
  • Messaging at v1. Email plus reply-to magic handles the first 500 transactions. A custom messaging surface is a 4–6 week build that adds little before liquidity.
  • Public ratings before 50 transactions. A handful of early ratings is noise that hurts more than it helps. Gate public ratings on completed- transaction count per supplier.
  • Algorithmic matching at v1. Operator-driven matching is faster to ship, easier to evaluate, produces better quality, and teaches the team what the algorithm should eventually do.
  • Mobile apps before web conversion. Web desktop + mobile-responsive handles 90% of B2B marketplace traffic. Native apps are a v3 question, not a v1 question.
  • Multi-region at launch. Pilot one region end-to-end before adding the second. Multi-region complexity at launch sinks more marketplaces than weak supply does.

Worked example · Dreilokale (Reference 01 → 02).

Dreilokale is the Swiss event-location matching platform Morvion built end-to-end. The architecture mirrors Reference 01 and is currently graduating into Reference 02 as liquidity grows.

  • Request flow. One structured request from the organiser (event type, party size, date window, region, budget band) takes under two minutes to complete.
  • Matching. Operator-curated tailored venue proposals back inside 48 hours. The operator console runs the matching today; algorithmic matching is queued for the next phase.
  • Dashboards. Organiser-side (track requests, see proposals, accept one) and venue-side (see inbound matches, respond inside the SLA) are different products.
  • Trust. Named operator behind the matching, displayed reply time on venue cards, completion count per venue.
  • Monetization. Lead credits per vetted request, currently, graduating to a hybrid take rate as liquidity passes the threshold.
  • Operator console. One screen the platform team runs the marketplace from. Open requests, supplier notification queue, escalations, refunds.

Regional notes · Switzerland, DACH, EU.

The architecture applies broadly. A few region-specific considerations from CH and DACH engagements:

  • Payment rails: TWINT is non-optional for any consumer-facing marketplace in CH. Stripe + TWINT via PostFinance is the default combination Morvion ships. For B2B, SEPA + invoicing is usually enough.
  • Multilingual: Zürich + ZH region operates in DE + EN; Vaud + Geneva + Lausanne in FR + EN; Tessin in IT + EN. Bilingual content is the floor, not a nice-to-have; the request flow respects language per region.
  • Regulatory: Swiss FADP (revised 2023) and EU GDPR/DSGVO both apply to marketplace data. Consent boundaries on the memory layer are tighter than US norms; cross-border data flows need an explicit lawful basis.
  • Holidays + closures: Swiss public holidays differ by canton; the matching layer respects that so a request landing on a Berne holiday doesn't wait until the Berne supply team is back. Single national calendar is wrong.
  • Trust expectations: DACH demand side weights response time and named operator higher than US norms weight star ratings. Adjust the trust-signal priority accordingly.
Field rule

A marketplace platform is not finished when both sides can transact. It is finished when both sides do less work per transaction than they would without it.

Marketplaces are built inside Digital Products & Platforms, with the trust and matching surfaces frequently extending into Experience Design & Interactive Worlds for the editorial layer. Engagements start with a two-week Discovery Sprint that audits the demand and supply sides, validates the request shape, and locks the data model before any production build.

For the long-form narrative on these patterns, see the field notes on marketplace design principles and marketplace trust signals. For the one-paragraph definition of the underlying term, see the glossary entry on marketplace platform. Hospitality marketplaces specifically are covered in the companion Hospitality Digital Stack Report.

Versioning of this report.

This document is versioned. Substantial revisions (new reference architecture, new cost band, new region notes) bump the major version. Minor refinements are silent. Current version: 1.0.0, published 2026-05-19.

Common questions.

What is a marketplace platform?
A marketplace platform is a two-sided software system that connects a demand side (requesters, buyers, organisers) with a supply side (operators, sellers, venues) through a matching layer, two role-scoped dashboards, and a trust system. The platform succeeds when both sides do less work per transaction than they would without it.
What does a working marketplace stack include?
Six layers: a structured request flow (4–7 questions only the platform can match on), a matching engine (operator-curated or algorithmic, sometimes both), two role-scoped dashboards (organiser-side and supply-side are different products), a trust system (reviews, response-rate badges, named-operator pages), a monetization layer (lead credits, take rate, subscriptions), and an operator console for the human in the loop.
How much does a marketplace platform cost to build?
Morvion engagement bands: early-stage curated marketplace (operator-driven matching, 10–200 supply-side accounts) lands €60–140k. Scale-stage liquid marketplace (algorithmic matching, 200–2,000 supply, public ratings) lands €120–280k. Multi-region marketplace (multiple jurisdictions, currencies, languages) lands €220–500k. A two-week Discovery Sprint at €18–25k typically precedes the build and locks the request shape + matching logic before any production commitment.
How long does a marketplace platform build take?
Early-stage curated: 12–18 weeks from kickoff to launch. Scale-stage liquid: 16–28 weeks. Multi-region: 24–40 weeks. A working operator dashboard on real data lands inside the first six weeks of any engagement. The first end-to-end transaction usually flows in week 8–10.
Why is the homepage not a search bar?
The moment you make supply scrollable, you're competing with Google search. And you lose, because Google ships a marketplace by accident every morning. Working marketplaces design the request → curated match flow first; the listing comes after, as a side effect. The homepage is a request flow, not a search box.
Has Morvion built a marketplace platform?
Yes. Dreilokale (live at dreilokale.ch) is the Swiss event-location matching platform Morvion built end-to-end, one structured request from the organiser, tailored venue proposals back inside 48 hours, with CRM, CMS, and email automation behind the matching. Reference architecture, request flow, dashboard shape, and trust signals are all drawn from that build.