TBBN Business Model

The single most important correction

Early drafts of this project described TBBN as "a marketplace where people trade items." That is not what got designed. What got designed is an exchange infrastructure layer — identity federation, listing exchange, trade matching, offer management, checkout orchestration, notifications, fraud scoring, and the SDKs/widgets/docs that expose all of it — that a reference consumer product happens to sit on top of. This distinction changes revenue model, legal exposure, architecture, onboarding, compliance, product strategy, investor positioning, developer experience, and network effects. Treat it as load-bearing, not a branding choice.

Comparable shape: Stripe (Stripe API → Stripe Dashboard/Checkout), Shopify (Shopify Platform → Shopify Storefront), Twilio (Twilio API → Twilio Console), Plaid (Plaid API → Plaid Link).

Two businesses, one company

Business A — TBBN Platform (infrastructure / developer business)

• Domains: tbbnetwork.com, api.tbbnetwork.com, developer.tbbnetwork.com, dashboard.tbbnetwork.com, sandbox.tbbnetwork.com, status.tbbnetwork.com.
• Customers: ecommerce platforms, marketplaces, consignment software, thrift software, classifieds, social-commerce apps — i.e. businesses, not individual sellers.
• Revenue: SaaS subscription, metered API usage overage, enterprise contracts, white-label widget licensing, support/onboarding. See pricing.md.
• Owns: identity federation, listing exchange, trade intelligence/matching, offer/trade-session management, checkout orchestration, notifications, fraud/compliance signals, analytics, developer platform, SDKs, widgets, documentation, merchant onboarding.

Business B — TBBN Exchange (consumer-facing reference implementation)

• Domains: exchange.tbbnetwork.com, trade.tbbnetwork.com, global.tbbnetwork.com.
• Customers: individual sellers, who register directly for a Marketplace profile (Phase 22 — see docs/business/conflict-resolution-log.md item 18) or arrive via a merchant's verification call. See docs/business/glossary.md for the exact identity-federation rule.
• Purpose: creates liquidity, proves the APIs work under real load, serves as the reference implementation merchants can study, demonstrates the network effect that makes TBBN valuable to a second/third/Nth merchant.
• Is simply the first customer of Business A's APIs — same relationship as the Shopify Storefront to the Shopify Platform. It should be one of the last things fully built out (Phase 20), not the first, because it consumes everything else.

Core business principles (non-negotiable)

TBBN does not currently handle: money, payment processing, escrow, taxes, commissions, shipping, customs, duties, fulfillment, returns, disputes, refunds, merchant onboarding, seller KYC.

Merchants currently handle: checkout, taxes, commissions, fulfillment, shipping, returns, disputes, customer service, seller management, compliance.

(Language note, founder-directed 2026-09-09: these were previously stated as an absolute "NEVER"/"ALWAYS." Changed to "does not currently"/"currently" — the behavior is unchanged, but a permanent claim is something to publicly walk back if TBBN ever does start processing a payment of some kind; a "currently" framing doesn't require that. See conflict-resolution-log.md item 17.)

This is what turns TBBN from a high-risk marketplace into a low-risk infrastructure company — it is the single most important business decision in the source specification, and every architectural choice in this repo protects it. The one narrow exception, scoped deliberately and kept as small as possible, is the single payment flow below.

The only payment flow TBBN is ever a counterparty to

Merchant SaaS billing — a merchant business pays TBBN for its plan (subscription + metered usage overage). This is ordinary B2B SaaS billing, handled by services/billing-service via Stripe Billing. TBBN does not currently charge an individual seller for anything — an earlier version of this document specified a second flow (sellers paying TBBN directly to boost/promote a listing); that flow, and the boost-payment-service that would have handled it, have been removed entirely. See docs/business/conflict-resolution-log.md item 14. Businesses are currently the only counterparty TBBN bills.

No other money currently touches TBBN. In particular, the trade-settlement amount a seller pays when accepting a trade is currently collected by the other seller's merchant, on that merchant's own checkout — TBBN only reserves items and redirects; see docs/architecture/trade-session-state-machine.md.

An earlier brainstorm proposed a "Global Liquidity Fee" (a % or flat fee TBBN would take on cross-merchant trades). That has been cut — see docs/business/conflict-resolution-log.md item 1 — because taking a cut of trade value makes TBBN a payment intermediary and undermines the entire "does not currently touch trade money" positioning. The network-effect value that fee was meant to capture is instead captured through usage-based metering on the merchant SaaS invoice, at a premium rate for cross-merchant events.

Target customers and how TBBN fits their business

Customer type	What they get from TBBN	Integration path
Marketplaces (Poshmark-style, resale apps)	Trade as a retention feature alongside cash sales; wider trade liquidity via cross-merchant reach	API + SDK, or Private-tier internal-only widgets if they don't want cross-platform trade
Ecommerce platforms (Shopify/WooCommerce/Magento merchants)	A "trade in" option without building matching/negotiation infra themselves	packages/plugin-shopify (and future WooCommerce/Magento/BigCommerce plugins) — install, not integrate
Thrift & consignment businesses	Trade options that keep inventory moving without new fulfillment headcount	Widgets embedded in existing storefront, minimal engineering lift, or point an existing Google/Meta-style catalog feed at TBBN instead (see docs/api/merchant-catalog-feed.md — specified, not yet built)
Classifieds platforms	Turns a passive listing into an active trade match, without becoming a payments company themselves	API + directory-service listing sync
Social commerce apps	Trade as a community/engagement feature	SDKs (React/RN first, others per roadmap) + widgets

Two adoption paths are deliberately both first-class, because target customers span sophisticated engineering orgs (large marketplaces) and thin-engineering small businesses (independent thrift/consignment shops): a pure API/SDK path for merchants who want to build custom UI, and a plugin/widget path (Shopify app install, embeddable <script> widgets) for merchants who want to ship in days, not months. Building only the API path would exclude most of the thrift/consignment/classifieds segment, which is a large share of the named target market.

Merchant tiers (capability ladder, mapped 1:1 to SaaS pricing — see pricing.md)

• Sandbox — evaluation only, no production access.
• Starter (Global) — global listing + global trading only.
• Growth (Premium) — adds Private + Both listing visibility, embeddable widgets, white-label option, seller access controls.
• Enterprise — adds Enterprise-only visibility (private trading between hand-picked enterprise merchants), dedicated infra option, custom workflows, SLA.

An earlier draft used two inconsistent tier namings (a GLOBAL/PRIVATE split in one place, a four-tier GLOBAL/PRIVATE/PREMIUM/ENTERPRISE capability list in another, and separate SaaS tier names Starter/Growth/Enterprise in a third). These are unified into the single ladder above — see conflict-resolution-log.md item 4.