A marketplace is only as trustworthy as the system underneath it. For a confidential, two-sided market handling the largest transaction of an owner's career, the architecture is not an implementation detail — it is the product promise. This Pillar is the operator-readable map of how Milly Books is built: the six services that compose the marketplace, and the three design choices that shape how they behave.
The framing that organizes the rest: the platform is a set of single-concern services that compose into one coherent product. No service tries to do everything; each owns one job, and the boundaries between them are deliberate. The result is a system where a seller's listing, its valuation, and its buyer matches are the same underlying data seen from different angles — which is exactly what a fair, confidential marketplace requires.
§ 01 · The six surfacesSingle-concern services.
Six services make up the platform. The marketplace app (cake-miniapp) is the authenticated product where buyers and sellers operate. The public site (cake-terminus) is the marketing and content surface — including this journal. The transactional backend (cake-trantor) is where every authenticated read and write flows. The data pipeline (cake-deep-thought) is the warehouse and intelligence layer. The infrastructure layer (cake-foundation) provisions and governs everything. And the feature store (cake-feature-store) is the scaffolding for the next generation of matching intelligence.
Each owns one concern. That discipline is what lets the platform evolve a surface without destabilizing the others — the public site can ship daily without touching the deal backend; the data pipeline can add a model without changing the app. The sections below walk each layer in the order a user encounters it, then close on the design choices that bind them.
No service does everything. Each owns one concern, and the boundaries are deliberate — that is what lets one surface evolve without destabilizing the rest.
§ 02 · The apps people touchMarketplace app, public site.
Two surfaces serve two audiences. The marketplace app is the authenticated product: a buyer browses a matched feed and submits offers; a seller runs a valuation, publishes a listing, and manages inbound interest. It is built as a fast, app-like experience because the people using it are making a career-defining decision and deserve a product that feels considered, not clerical.
The public site is the anonymous surface — the marketing pages, the buyer-profile and listing previews, the valuation entry point, and this journal. It exists to be found: it is search-optimized, server-rendered for speed, and structured so a prospect can learn how the marketplace works before ever creating an account. The two apps share a design system and a visual language, so the move from "reading the journal" to "running a valuation" to "managing a live deal" feels like one continuous product, not three. The marketplace app Pillar walks the authenticated product feature by feature.
§ 03 · The transactional backendWhere deals actually move.
Beneath the apps, the transactional backend is the system of record. Every authenticated action — a listing published, an offer submitted, a counter threaded, an escrow advanced — is a write that flows through it. It is the layer where correctness matters more than anything: an offer chain that holds up in due diligence, a document trail that does not depend on anyone's inbox, and state transitions that are atomic so a deal is never left half-advanced.
The backend is organized around the deal lifecycle — listing, offer, agreement, escrow, close — as an explicit set of states with explicit transitions. That structure is what makes the deal mechanics auditable and what lets the product guarantee, rather than hope, that a deal moved correctly from one stage to the next. The full treatment of the state machine, the offer chain, and the escrow integration lives in the deal-workflow backend Pillar.
§ 04 · The intelligence layerValuation and matching.
The data pipeline is where the platform's intelligence lives. It ingests agency data from the management systems agencies already use, normalizes it, and feeds two products: the Book Valuation Engine and the matching engine. Both rest on the same normalized data, which is why the valuation a seller sees and the fit a buyer sees are consistent — they are computed from one source of truth, not two parallel estimates.
The pipeline runs on a scheduled, observable cadence: data flows in from the agency-management systems, gets reconciled and quality-gated, and produces the scored outputs the marketplace consumes. The intelligence layer is intentionally separated from the transactional backend — the pipeline can recompute matches or refine the valuation model without touching live deal state. The ingestion mechanics are covered in the AMS ingestion page; the scoring model in the matching and appetite-scoring engine; and the reporting cadence in the KPI orchestration page.
§ 05 · InfrastructureThe layer that governs.
The infrastructure layer provisions and governs the whole platform. It defines the environments, the databases, the routing, and the deployment discipline as code — which means changes to the platform's shape are reviewed, versioned, and reversible rather than configured by hand. For a system handling confidential financial data, that change-control discipline is part of the trust model, not an operational nicety.
The feature store sits alongside it as forward scaffolding — the layer that will serve the next generation of matching and valuation models as the marketplace's data deepens. It is deliberately lightweight today; its presence reflects a design choice to build the intelligence layer's foundation before it is load-bearing, rather than retrofitting it later.
§ 06 · Three design choicesWhat shapes everything.
Three decisions shape how the whole platform behaves. They are choices, not constraints — each was made deliberately, and each has consequences a user feels.
- Anonymous by default. Confidentiality is a property of the data model, not a toggle. A listing exposes the shape of the book, never the identity, until the seller advances a specific buyer. This is the choice that lets owners test the market without risking exposure.
- One model, two views. The seller flow and the buyer flow read and write the same records. There is no export or reconciliation between a "seller tool" and a "buyer tool" — the listing is one object both sides act on, which is what keeps matches and offers coherent.
- Data-anchored. Valuation and matching run on the same normalized pipeline. The number a seller anchors on and the fit a buyer sees come from one source, so the marketplace negotiates from shared facts rather than competing narratives.
The architecture is the product promise. Anonymous-by-default, one-model-two-views, and data-anchored are not engineering preferences — they are the structural guarantees that make a confidential, fair, two-sided market possible.
§ 07 · How it composesThe whole, from the parts.
Put together: a seller enters the public site, runs a valuation powered by the data pipeline, and publishes an anonymous listing through the marketplace app, which the transactional backend records. The data pipeline scores that listing against every buyer profile; matched buyers engage through the app; offers thread through the backend; and the deal advances to a funded close — all on infrastructure that is versioned and governed as code. Six services, one continuous path.
The composition is the point. A prospect reading this journal, a seller running a first valuation, and a buyer managing a live deal are all touching the same coherent system — and the design choices above are what make that coherence possible. The platform-success thesis covers what this architecture produces for operators that the legacy broker process cannot, and the platform guide is the operator-side walkthrough of what the platform is and how it differs.
Six single-concern services composing into one path — public site to valuation to listing to matched buyer to escrow. The coherence a user feels is the architecture, not a coincidence.
This overview is the map; the deeper pages are the territory. The marketplace app covers the surfaces people touch; the deal-workflow backend covers the deal mechanics; the data pipeline covers the intelligence layer; and the seller persona architecture covers how the product adapts its voice to different kinds of sellers.