diff --git a/docs/maker-platform-pr-faq.md b/docs/maker-platform-pr-faq.md index 2b511d1..d0b631e 100644 --- a/docs/maker-platform-pr-faq.md +++ b/docs/maker-platform-pr-faq.md @@ -335,6 +335,20 @@ Three things, in the order they matter (the buyer value prop, memo §13): *you* chose to follow and the makers *they* vouch for, never an algorithm pushing whatever converts (§7, "The buyer-facing feed"). +**As a buyer, where do I actually shop — is there an app, a site, a login?** +Deliberately almost nowhere at first, and that's the point (§13). **At launch the platform +is invisible to you:** you buy on the *maker's own storefront*, as a guest, the way you +already do — there's no "Maker Collective" destination to sign up for, and "come back for +the next drop" runs through the maker's *own* channels (their email, Instagram, Discord). +The one thing the platform quietly powers is **follow/notify**, so you hear about the drops +you care about. Later — Phase 2+, opt-in — a light **"your makers, in one place" feed** +appears: followed makers' drops, "buy it again," and the Curated-By picks of makers you +follow, with a light identity you can return to. But it's a *retention upgrade* on top of +the makers' own channels, **pointedly not** a marketplace you evangelize ("I shop on X") — +every item still traces to a maker *you* chose to follow, and the platform never becomes +your primary relationship; the maker does. The mental model: **you're a fan of makers, and +the platform is the wiring that keeps you connected to them**, not a store you shop at. + **I pre-ordered, and the maker never delivered. What protects me?** This is the *signature* risk of commitment commerce, not an edge case — the model collects money before delivery, so "a verified maker takes pre-orders/deposits and ghosts" is the @@ -393,6 +407,42 @@ which silently flip you to merchant-of-record and into facilitator-tax territory The stance holds *only* at Standard accounts + direct charges + `application_fee` (§7, "Money flow"). +**"You own the buyer" — doesn't that collide with GDPR and CAN-SPAM?** +No, because "own" means **usage-rights to a *consented* relationship**, not a license to +message anyone (§7, §11). The mechanics: the network captures **email + per-type marketing +consent at checkout** and pushes the subscriber to the **maker's own ESP**, which is the +source of truth and owns everything after — compliant unsubscribe, suppression, +deliverability. So what the maker owns is the right to market — *on any channel, on or off +the network* — to buyers **who consented**, with the unsubscribe machinery a real ESP +already enforces. That's the precise inverse of Etsy/Amazon (who forbid off-platform +marketing because the captive buyer is *their* asset), and it's lawful *because* it's +consent-first. Two more structural points a privacy reviewer will want: +- **Two consent domains, strictly separate.** *Maker-originating* marketing lives in the + maker's ESP (the maker is controller); *network-originating* communications (the buyer + feed, follow notifications, aggregate digests) run on **network-communication consent the + network owns** — and the network **never borrows a maker's ESP list** for its own sends. + That separation is what keeps every personal-data flow attributable to a lawful basis and + a controller. +- **The cross-maker identity graph is opt-in by design.** Being recognized across makers is + a *buyer* opt-in, not a default-share — so the architecture is already aligned with the + strictest "no sharing without affirmative consent" reading rather than retrofitting + opt-outs. The posture is **build to the strictest law** (CCPA/CPRA plus the newer state + laws, and **GDPR the moment EU buyers appear**), with access/deletion and + opt-out-of-sale/sharing built in. (Per the handbook, "consent" defers to the OHM *consent* + RFC, not a local definition.) + +**Isn't the referral "wallet" itself a regulatory problem — stored value?** +No, by deliberate design (§11). The fee-offset wallet credits a maker against their **own +future platform fees** — a *discount / accounts-receivable entry*, not a balance the maker +can withdraw or spend with third parties. So it's neither stored value, a prepaid-access +instrument, nor transmittable money, and stays outside the money-transmission and +stored-value regimes *by construction*. The line is **cashing out:** the moment a credit +becomes withdrawable cash, that's the deliberate crossing that re-opens the door — which is +exactly why cashable payouts are **gated to Phase 2 behind a rented licensed transmitter** +(Stripe Connect/Treasury, Dwolla), never a toggle flipped early. (Flagged for counsel: +verify the non-cashable design against each state's stored-value / prepaid-access +definitions before launch — *flag and verify, not legal advice*.) + **What's the actual moat? Can't a competent team rebuild this in a week with LLMs?** The memo's organizing lens (§1): cheap production destroys **stock moats** (accumulated build/features) and rewards **flow moats** (data, network, switching @@ -685,6 +735,29 @@ audiences and vouching for each other — but that's the **unvalidated keystone* it's gated on discovery (§8): do enough audience-having, vouch-willing makers exist in one tight community? Everything is downstream of that question. +**What's the falsifiable hypothesis here — and what would make you kill it?** +The thesis rests on one keystone, stated to be falsifiable, not asserted: **demand can be +*earned* — makers bring their own audiences and vouch for each other — rather than bought** +(§4, §13). The go/no-go is concrete (§9 decision gates), and a failed gate *stops the build*, +not just dings it: +- **The dozen-maker gate.** Can you reach ~a dozen makers in one tight community who feel the + *same* commit-then-make pain *and* refer you onward? Two makers justify a portable data + model; they do **not** justify building the platform. If the dozen doesn't cohere, you + don't build — full stop. +- **The behavioral demand test (the decisive one).** Discovery so far talked only to makers — + and *greenfield* ones with no audience. So before the platform is built, run a **real + instrumented drop** and measure whether a referral from maker A actually converts A's + buyers into followers of B. If that propagation doesn't happen, the network thesis is + falsified at the cheapest possible point. +- **The North Star as a live kill-signal.** Post-launch the one number is **the share of GMV + that is cross-maker-referred** (§12) — near-zero for a pile of disconnected storefronts, + rising *only* if the network does real work. A persistently low North Star is the explicit + failure mode ("a great tool that never becomes a network"), and it can't hide behind a + vanity supply count. +The honest posture: **the tool is a real business even if the network never lights** — so +failure is survivable, not ruinous — but the *network*, the actual moat, is gated on a +falsifiable demand test the org commits to running *before* betting on it. + **What's the sequencing? You keep saying "don't launch a marketplace."** Four acts, each viable alone, each earning the next (§5): **Tool** (the commitment-commerce engine — a real business at zero network liquidity) → **Community**