Every such marketplace is assembled from three roles — two reusable, one the sponsor’s. Read the four diagrams in order: each zooms in one level, then the last pulls back to show why the model scales.
A working thin-market exchange is not one monolithic product. It is a composition of three distinct responsibilities. The trick that makes the economics work is that two of the three are generic — built once and reused across every market vertical — while only the third is bespoke to a particular market and its sponsor.
The diagrams below use a single color throughout so the same components are recognizable as they reappear at each level of zoom. Learn the three colors once; they carry the whole story.
The DeeperPoint thesis: the frictions that keep markets thin are common across thousands of markets — so the engine that neutralizes them is built once and reused. A sponsor adds only their market’s business logic, instead of rediscovering the same problems alone.
Curatorial & feeder systems
Domain knowledge wiki, reference library, and a synthetic population. Feeds real-world data into the marketplace. Owned by curators / a specialist setup service.
Matching engine
Schema compiler, candidate matching + scoring, deal-brief assembly, precompute. The reusable engine — built once, replicated per vertical. Drawn white with a dotted edge in the diagrams to mark it as the shared, reused element.
Market-vertical layer
Branded front-end UX plus auth, ads, payments, piggybacked services. Owned by the market sponsor.
Three roles, left to right. The feeder systems supply domain knowledge and a synthetic population; the matching engine turns that into matches, deal briefs and a cache; the market-vertical layer presents it to the people in that specific market. The middle block is identical from one vertical to the next. The feeder↔engine link is two-way: matching results feed gaps back so the knowledge, population, and weights keep improving.
The third role is the only one that changes between markets. A sponsor may build it themselves or buy it from a paid market-forging service — either way, roles 1 and 2 are reused unchanged.
The same three colors, now as swimlanes showing the operational flow for one vertical. Domain knowledge and a watermarked synthetic population feed the engine; the engine matches, scores, assembles deals and writes a static cache; the sponsor’s front end reads that cache. Cross-lane arrows show where one role hands off to the next.
Everything the engine does is deterministic, which is what lets the whole run be precomputed once into a static cache — a fully precomputed deployment runs at zero per-visitor cost. (See Figure 3.)
Zooming into the matching engine. The engine ingests the population, runs a two-stage match funnel (a cheap deterministic gate, then semantic ranking and weighted per-role scoring), assembles deals with facilitator sub-deals, and generates the match story. Because every step is deterministic, the run can be materialized — computed once on write, then read cheap — into two projections: a match cache (the deal/story experience; Mode 1 serves it, Modes 2–3 compute live) and a public profile / gallery cache (a public-only view that powers live galleries and search).
Both projections share one mechanism but differ in contract: the match cache may use private fields and (in the demo) is frozen synthetic data; the profile / gallery cache is a public-only projection of real profiles, regenerated per record on write. Rule of thumb: precompute the gallery, compute the match. The feeder↔engine links are two-way: match gaps feed back to improve the reference library (knowledge), the synthetic population (coverage), and the matching weights — a continuous-improvement loop.
Pull all the way back. Three different markets, side by side — and each is a complete, independent stack: its own knowledge feed (violet), its own copy of the matching engine (white), and its own storefront (amber). The engines look identical because they are the same open-source build, replicated — not because they share one running instance. That is the economic argument: the expensive engine is written once, then cloned per vertical, so launching the next market means authoring only a feed and a front end.
Each vertical deploys its own engine today — the same open-source components, separate instances. A single multi-tenant engine serving a “constellation” of marketplaces is a possible future, not the starting model. The reuse is in the build, not a shared runtime: you clone the reference implementation rather than reinvent it. Each deployment also runs its own feeder↔engine feedback loop, so every vertical’s knowledge, population, and matching improve independently.
Strip everything else away and this is the decision a market builder faces — rediscover the same frictions alone, or start from a solution already grounded in the theory of why markets stay thin. The reusable engine carries any pairing as far as the Deal Brief — the last step common to every market — and the sponsor’s own layer (contracting, payment, fulfillment) takes it from there.
Figures 1–4 are the build-side view. To see what a participant experiences inside one of these markets — from anonymous discovery to a Deal Brief — read How It Works, or open the live demo.