# Maker Platform — Strategy & Architecture A working memo distilling the thinking so far. It serves makers in general, but launches into one dense community first (the *beachhead*, §2/§5). The aim is to keep two doors open — a paid consultancy that's real today, and an option on a larger network play — without over-committing to the second before the evidence justifies it. > **Grounded in the Open Human Model.** Every principle in this memo — *trust, consent, reputation, harm, recourse, value, agency, dignity* — is meant to rest on the shared definitions in the [**Open Human Model (OHM)**](https://rfc.wiggleverse.org/p/ohm/c/default/), Wiggleverse's version-controlled dictionary for the words that systems acting on behalf of humans turn on. Where this memo and an OHM RFC disagree, **the RFC is canonical**; where a load-bearing concept here isn't yet defined in OHM, defining it is itself OHM work (not license to coin a local meaning). The reputation/trust model below is the first place this bites — see §10 (and §12 #1). --- ## 1. The lens: stock moats vs. flow moats The organizing idea behind everything below. - **Stock moat** = accumulated build, features, or content — a one-time lead. As production cost collapses (cloud did this to infrastructure; LLMs are now doing it to software production), stock moats trend toward zero, and any *new* stock advantage is matched in weeks. - **Flow moat** = data, network, switching cost, regulation, embedded workflow. It compounds with every customer and every day of use, and cheap production can't shortcut its accumulation. The diagnostic for any product: *if a competent small team could reproduce the functionality in a week with LLM assistance, what does the customer still pay for?* Whatever survives is the real moat; if nothing survives, build-cost was the whole moat — the exposed position. Cheap production lowers cost **symmetrically** — for every entrant at once — so it never picks winners. It commoditizes the build layer and pushes competition *up* to the moats it can't erode. Don't pick a fight where build-cost was going to be your only moat. --- ## 2. The thesis Build for **independent makers** — positioned as "the curated maker marketplace before resellers polluted it," but executed so the durable value is flow, not stock. **The core primitive: commitment commerce.** The entire "gnarly 20%" that generic tools serve badly is one mechanism wearing many costumes. Pre-order, raffle, drop, monthly club, made-to-order commission, deposit-and-waitlist — every one is *collect committed demand before production, then make against it.* That's the inverse of Shopify's *stock-then-sell* (make it, shelve it, someone buys it), which is exactly why Shopify and generic tools serve makers badly: makers run on *commit-then-make*. The category you're building is **commitment commerce**, not storefront commerce — the drop/pre-order/club/commission cadence is the engine, and the storefront is just its surface. Two halves, treated differently: - **Commitment-commerce engine (the real product).** The maker-native cadence layer Shopify lacks: scheduled drops, pre-orders and deposits, raffle/queue allocation, made-to-order workflows, recurring clubs/memberships, digital-file delivery + licensing where relevant, and variant/bundle handling. This *is* the gnarly 20% and the reason vertical infrastructure here is defensible — emphatically *not* "the same as Shopify." (The white-label storefront is the commodity surface, subsumed here: build the least of it you can, rent the rest.) - **Cross-maker demand network (the moat).** The flow asset, accruing as a *byproduct* of the engine. Every drop/pre-order captures a buyer who *follows* a maker and commits early; a base of drop-followers across many makers is the embryonic cross-merchant identity network — the niche-scoped Shop Pay equivalent. Stock commerce gives you people who bought once; commitment commerce gives you people who *wait for* makers and commit ahead — a far stronger flow asset. Reputation-staked cross-maker curation turns that into *earned* demand, not just relocated demand. The reframe: commitment commerce is not a feature of the storefront — it *is* the platform, and the mechanism that builds the flow moat, rather than something engineered separately alongside it. **The beachhead principle.** "Makers in general" is the eventual market, but a network cold-start needs *density* — so launch in one craft community tight enough that word-of-mouth substitutes for a marketing budget, and where you show up as a *member, not a vendor*. Expand to adjacent communities only after the first compounds. The vertical-selection method and a worked candidate (miniatures → dice → broad tabletop) are in Appendix A. **Business model (detail in §7):** the **network is the product and the value capture** (referral take + network subscription, charged identically whether a maker is on your storefront or Shopify); the **storefront is an optional, SaaS-priced convenience — never GMV-fee'd, never sold as hosting.** You are a *vertical commitment-commerce product*, not a hosting company; a partner/consultant network onboards the high-touch tail. --- ## 3. Positioning: what's yours vs. what's commodity The cross-merchant inclusion mechanism already exists and is commoditized — Shopify Collective, Carro, and Shopify's Product Network all let merchants sell each other's products. Feasibility is de-risked, but it means **you cannot win on the plumbing.** If the product is "Collective for makers," Shopify extends Collective and you're gone. Your differentiation is the layer the commission-optimized networks structurally can't have: - **Verified provenance.** "Actually handmade/made by this person" is the trust signal buyers and AI agents can't get elsewhere, and it *appreciates* as AI-generated and drop-shipped fakes proliferate (Etsy is being flooded now). This is flow; the aggregation tech is stock. - **Reputation-staked curation, not pay-for-placement.** The central danger: commission-driven inclusion drifts curation from "what's genuinely good" to "what converts and pays," rebuilding Etsy's pollution from inside, laundered through trusted faces. Inclusion must be an editorial/social act with the curating maker's standing on the line. - **Community standing.** The demand problem is a community problem, and community is founded, not acquired. Longer term, the verified-supply graph becomes **agent-ready rails** — the trustworthy, structured, real-time-inventory supply layer AI shopping agents need and can't manufacture by scraping. That repositions the moat from "win consumer eyeballs" (unwinnable for a newcomer) to "be the verified maker-supply layer agents route through." --- ## 4. Honest risks and hard truths - **The graveyard is real.** Goimagine, Artisans Cooperative, Folksy, Storenvy, Amazon Handmade — "Etsy but actually handmade" has been built many times and stays small. The reason: **curation fights liquidity**, and curation is a *seller-side* value proposition. These platforms recruit angry makers (supply) and die for lack of buyers (demand). Etsy's drift into mass-produced goods wasn't betrayal — it was the gravity of GMV growth. - **No demand advantage yet — the binding constraint.** Demand at marketplace scale must be *earned*, not bought; paid acquisition against Etsy, Amazon, and agents is the losing game the graveyard played. Early on the network *pools existing maker audiences* (reshuffle), it doesn't create net-new buyers — the correct cold-start move, but don't mistake it for solving acquisition. - **Buyer-ownership tension.** Some makers guard their customer lists and will resist shared cross-merchant identity. If they want the cross-promotion demand but not the shared identity, the network's conversion advantage is capped. Surface early (and see the opt-in design in §7). - **n = 2 is learning, not validation.** The engineer's trap is over-abstracting for two clients when the right abstraction only reveals itself around ten. - **Commitment commerce carries financial/delivery liability.** Taking money before delivery inherits structural delivery risk — chargebacks, non-delivery, makers who collect pre-orders and don't ship. This is *why* the 20% is gnarly (financial risk, not just UX). The design answer (§7): stay out of the money flow so the maker, as merchant of record, carries it. - **Raffle/lottery legality.** The raffle drop mechanic can be regulated as a lottery/gambling depending on jurisdiction — the one primitive with real compliance exposure. Understand it *before* building it as a headline feature. - **Campaign vs. cadence is a product fork — pick cadence.** Episodic, project-scale crowdfunding is owned by entrenched incumbents (Kickstarter, Gamefound, BackerKit — Appendix B). The unserved gap is the *continuous* drop cadence (the biweekly drop, the monthly club). Don't drift into competing with Gamefound; own the continuous-relationship layer they don't serve. - **Volunteer-core sustainability is the single point of failure** (given the non-profit/volunteer model, §7). LLMs make a smaller core go further but don't fix volunteer attrition or bus-factor. The parts touching money, catalog data, and verification need *reliability*, not best-effort — so the critical core (network service, ledger, verification) must not be bus-factor-one. The historical killer of volunteer orgs is *sustaining*, not building; transfer the rigor you'd spend on fundraising onto this. --- ## 5. Sequencing: earn into the marketplace, don't launch one Four acts, each viable on its own, each earning the right to the next. No stage depends on demand you can't yet generate. 1. **Tool.** The verified-maker commitment-commerce engine with a white-label storefront as its surface — genuinely the best home for a real maker. Useful at zero liquidity. Accrues supply, a structured provenance-stamped catalog, *and* a base of drop-followers. *A real business even if the network never lights.* 2. **Community.** Narrow to one craft scene tight enough that word-of-mouth substitutes for a marketing budget (the beachhead). Add cross-maker discovery with an editorial point of view — the demand-generating feature you build rather than buy. 3. **Marketplace.** Light the curated cross-inclusion network once supply density and community exist — it *emerges* from accumulated follows (§7), rather than launching cold into the graveyard. 4. **Infrastructure.** Expose the verified-supply graph to agents; become the rails. **Selection criterion that decides everything:** pick the community where you show up as a *member, not a vendor* — where you already have, or can authentically build, real standing. --- ## 6. The immediate engagement (the first makers) A good investment **if** you build the right common infra. The wasted version is a generic storefront engine ("the same as Shopify") — the stock layer, valueless in every branch. The reusable assets worth owning, none of which is a storefront builder: 1. **A clean, portable, verified catalog data model that you own.** Cheap to do well now, expensive to retrofit later. 2. **The commitment-commerce primitives (the engine)** — scheduled drops, pre-orders/deposits, raffle/queue allocation, recurring clubs/memberships, made-to-order workflows, digital delivery + licensing, variant/bundle handling. The portable, vertical-spanning core; the storefront is just its surface. 3. **Standing in the beachhead community** and the first reference relationships. **Operating rule: build the maker-shaped 20%; rent the 80%.** Use a template, headless setup, or even Shopify itself for the commodity storefront parts. Let this be paid consultancy whose real return is knowledge, references, and a portable data asset — a cheap option on the bigger play. --- ## 7. Architecture The money-flow stance and the first network feature turn out to be the same decision viewed twice; the rest of the section builds out from there. ### Money flow: stay out of it (the "no") The white-label model enforces this: each storefront is the maker's brand on the maker's own payment processor, so **the maker is merchant of record by construction.** The money never touches you — you sell software, they run commerce. This is *cleaner than Kickstarter*, which is itself in the money flow (processes pledges, takes a cut, pays out) and only disclaims *delivery* liability; here you avoid both the flow and the delivery liability structurally. **Why staying out is right:** no money-transmitter/escrow licensing (holding customer funds triggers state-by-state MTL in the US); no chargeback exposure (it hits the maker's processor, not you); no delivery-risk balance-sheet exposure; clean SaaS margins and a faster launch; and it's maker-aligned (their brand, processor, payouts, customer, data). The cost is forgoing payment take-rate — but that's exactly the slice that carries the risk you're declining, a fair, deliberate trade. The cross-maker identity moat doesn't need checkout anyway: **the asset lives at the *follow*** ("who follows which makers and commits early"), captured at the account / "notify me" / club layer you own regardless of whose processor runs the charge. If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — but it is a *dial, not a single choice*, and only one setting preserves the stance above. Two independent knobs decide who is merchant of record and who eats the risk: - **Charge type.** *Direct charges* keep the **maker** as MoR — disputes and chargebacks hit the maker's balance, the maker pays the processing fees. *Destination charges* and *separate-charges-and-transfers* make the **platform** MoR — your balance is auto-debited for disputes, and you are now indirectly collecting and transmitting the buyer's payment, i.e. a **marketplace facilitator** for sales-tax purposes (§11). - **Account type.** *Standard* accounts leave negative-balance and dispute liability with the maker. *Express/Custom* push it onto the **platform**, with Stripe holding reserves against *you* for connected-account shortfalls. The stance holds **only at Standard accounts + direct charges + `application_fee`**: the maker stays MoR, disputes stay on the maker's balance, you skim a fee without entering the flow. The trap is that Stripe's own marketplace tutorials default to *destination* charges (the canonical "marketplace" pattern), which silently flips every one of those properties — the payments-layer cousin of the "buy through their store" creep this memo warns about elsewhere. So **the Connect configuration is a legal-posture constraint, not an implementation detail.** The default money model remains the out-of-flow ACH/invoice fee below; Connect is reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts), and even there uses the arm's-length setting. *(Verify per account type and per state with a payments/SALT attorney before architecting. Not legal advice.)* ### Unified phasing One phasing governs the whole build; everything below references these stages. - **Phase 1 — tool + stateless referrals (out of money flow).** White-label storefront on the maker's own processor; Curated-By via stateless signed tokens; non-cashable fee-offset wallet. No shared identity, no consent complexity, no money movement. A real consultancy/tool business on its own. - **Phase 2 — shared identity + the cashable-payout rail.** Shared auth + follow relationships + the consent-gated cross-maker graph (the durable network effects: follows, cross-session credit, niche-scoped recognition/conversion lift). Phase 2 also lands **one** cashable payout rail (Connect / mass-pay) that simultaneously unlocks cashable maker wallets, kit pure-supplier payouts (Appendix C), and the verified taste-maker tier — three consumers of a single scoped crossing. Optional Connect `application_fee` for transaction economics here too. - **Phase 2+ — buyer-facing feed.** The consumer surface where the marketplace *emerges* from accumulated follows (below). - **Phase 3 (much later, optional, opt-in) — shared checkout.** The only point the money-flow question returns — chosen by makers because it converts better, never forced. ### "Curated By This Maker" — the first network feature Each maker's storefront carries a **"Curated By This Maker"** section featuring other *verified* makers' products they genuinely admire. It's the demand network as a concrete, shippable surface — and it works at **n = 2**, the holy grail for a network feature. **What this is — and the name matters: a verified merchant referral network, *not* retail media.** The two look similar (a curated set of products with outbound links and attribution) but encode *opposite governance*: retail media is **paid placement** (highest payer wins the slot), while a verified merchant referral network is **reputation-staked vouching** (placement is earned; the curating maker's standing is on the line). The name is a structural guardrail — a thing called a *verified merchant referral network* can't quietly start selling slots without becoming a self-evident lie. Never frame or price it as retail media; that framing's gravity is toward selling placement, rebuilding Etsy's pollution through trusted faces. **Targets are verified makers on controllable storefronts ONLY — never walled-garden listings.** The network never points its curation, buyer feed, or agent feed *outward* at an Etsy/Amazon/eBay listing. This is a **value-system rule, not a technical limit**: every such link would lend the community's trust and a maker's audience to the captive-commerce model this enterprise is an alternative to. A walled-garden-only maker is an **invitation target, not a curation/destination target** — "I'd feature your work the moment you own your commerce" is the pitch, and the *absence* of a link is the recruiting signal. (It also sharpens the moat: when every target is a verified controllable-storefront member, the "sincere vouch vs. paid slot" gray zone disappears.) Full participation matrix in Appendix D. **The fork — what "buy" means:** - **(A) Referral / handoff — build this.** Checkout hands off to maker B's own store and processor. A vouches, B fulfills and is paid, A optionally earns a referral credit. Money stays siloed; A is never merchant of record for B's goods. Out of the money flow. - **(B) Consignment / resale — avoid.** The buyer checks out on A's store for B's product; A becomes MoR for B's goods and owes B a payout — recreating the delivery-and-payout liability you designed out (mechanically what Shopify Collective is, and why it needs Shopify Payments in the middle). Model A is reputation-staked human curation (the anti-pollution, can't-be-gamed kind that *is* the moat), it rides each maker's existing traffic, and it's structurally aligned (A only features B if A rates B's work). Watch the phrase **"buy through their store"** in any spec — it's where (B) creeps back via a unified-cart "convenience" that drags you to merchant-of-record. Hold the line at handoff until a shared *opt-in* checkout is a deliberate Phase-3 decision. **Guardrails:** - **Attribution is stateless — no identity layer required.** A signed referral token (origin maker + item + expiry + nonce) rides the A→B handoff into B's order; you read it to bill B and credit A. It tracks the *referral path*, not the buyer, so it works in Phase 1 for guests and sovereign makers. Persistent identity is only for the *durable* effects (follows, cross-session credit). - **Commission-corruption trap.** When Curated-By pays well, curation drifts to "feature whoever converts/pays most." Keep it reputation-staked: cap how much any maker can feature, make it visibly personal (name + face), prefer "A owns/uses this," and never sell slots. The sincere vouch is the whole value. - **Complementary, not substitute.** Nudge toward complementary makers (a maker surfaces an adjacent craft, not a direct rival) — complementary curation is generative; substitute curation is cannibalistic and makers won't do it. ### How the platform gets paid Out of the money flow, your fee is a **platform fee billed in arrears via ACH/invoice**, explicitly separate from processing (the comparable is Checkout Page: $29/mo, 0% on top of the maker's own Stripe). - **Tiered "graduate" pricing.** Starter: $0/low monthly + a modest **percentage** (≈2–4%) on captured orders (cold-start-friendly). Pro: flat **$29–49/mo + 0%** (predictable, easy to collect, at scale). Auto-graduate by GMV so makers don't overpay. Use a **percentage, not a per-order flat fee**, on low-AOV makers (a flat $0.50 over-taxes a $12 item). - **Charge on captured/fulfilled orders, not pledges** — don't bill money that never cleared. - **Market the all-in transparently:** "our fee + your own processor ≈ X% vs Etsy's ~20%." Not bundling processing is the wedge — say it in numbers. **Referral economics.** On a referred order, charge Maker B a **referral fee** (≈15%, Faire/Amazon-Handmade convention) and *independently* credit Maker A. Keep them as **two separate events** — B→Platform (a fee on B's invoice) and Platform→A (a credit you extend) — so you're **principal on both sides, never a conduit** moving money B→A. That independence keeps it out of money-transmission territory, and holds *only* while A's credit is non-cashable. - The referral fee **subsumes** the standard fee on referred orders (one clean "15% because referred"), rather than stacking toward Etsy-like ~19%. - **B's fee and A's credit are independent numbers; the spread is platform margin** (e.g., charge B 15%, credit A 10–12%, keep 3–5%) — one of the few places the network itself generates revenue. - **Non-cashable fee-offset wallet.** A's credit draws down *future platform fees first* — driving the curation flywheel ("curate → wipe out your fees"), lowering collection risk, and cleaner on tax (a fee discount, not income). **Cashing out re-opens the money-flow door** (rent BaaS — Connect/Treasury/Dwolla); a deliberate Phase-2 crossing, not a toggle. - **Pending → cleared settlement.** Credit A as *pending* (not spendable) and hold B's fee pending; settle **both legs together** after B's refund window (≈14–30 days) closes, so in-window refunds void both atomically with zero clawback. Negative balances are a debit on a continuing account: reverse pending, then available, then push any shortfall to the next ACH invoice; keep the ACH mandate active through offboarding; a rolling reserve only if a few high-volume curators make it material. ### Identity, sovereignty & the opt-in network **Separate authentication (infrastructure) from identity ownership (policy).** Run **one shared platform auth** under every white-label store; express sovereignty as a *data-visibility policy* on top — never by splitting auth per store. - **Sovereign maker:** full accounts/logins (on your shared auth), customer data private to them, zero network exposure. Sovereignty means *your buyers are private to you* — **not** "run your own login" and **not** guest-only (guest-only is *less* ownership, not more). - **Collective maker:** opted-in buyers participate in the cross-maker graph. - **Centralize auth always** — it's commodity infrastructure *and* the network's foundation. If auth fragments per store, even opted-in makers have no shared substrate to network across. The maker's choice is a flag on one system, flippable later without re-platforming. - **Two consent layers:** the *maker* decides whether their store participates; the *buyer* decides whether they're recognized across the network (GDPR/CCPA). Build both from the start. **What "own the customer" means — usage-rights is the headline** (validated, §8). Makers mean **usage rights**: the buyer relationship is *theirs to market to, on any channel, including off the network*. This is the precise inversion of the walled-garden restriction (Etsy/Amazon forbid direct off-platform marketing because the captive buyer is *their* asset), so it's the sharpest anti-walled-garden promise — **and you can grant it unconditionally**, because you don't monetize the captive relationship. It also *subsumes portability*. So: **usage-rights ownership is the headline; network-graph *privacy* (buyers hidden from the cross-maker graph) is a separate, optional opt-out** for the fortress-minded subset — not the core meaning. Operational machinery in the consent subsection below. **Opt-in network model — carrot, not stick.** It self-selects the commons-minded makers the network works for. The benefit must be **concentrated and visibly fast** or opt-in becomes a ghost town. Keep the asymmetry **additive** (joiners get referral income, placement, cross-promotion, fee offset, feed surfacing) — never **punitive** (don't cripple the standalone storefront to force joining). Design for **granular** participation, **reciprocity** (surfacing proportional to participation), and a **social-proof opt-in moment** ("makers you respect sent each other 200 buyers last month — want in?"). **Don't bundle "on our storefront ⇒ on the network."** Forcing full network participation on storefront makers is the coercion the opt-in model rules out, and it weakens the storefront's standalone (n=1) value. Split two switches: **catalog presence** (your products *can* be discovered/curated/fed) is reasonable to **default-on (opt-out)** for storefront makers (low-friction, low-sensitivity); **buyer-identity participation** (your *buyers* are recognized cross-maker) stays a **separate, consent-gated opt-in** (sovereignty-sensitive, and it's the buyer's data). Take the convenience (auto-catalog-sync); never the coercion (forced identity sharing). **Why this is the defensible core.** Shopify *won't* build cross-merchant shared identity — its customers (sovereignty-seeking DTC merchants) would experience it as the platform claiming their buyers, betraying the exact promise Shopify sells. Shopify does the *resell* network (share *products*) but not the *referral* network (share *buyers* with attribution). Your bet: community-embedded makers relate to shared identity as *belonging*, not theft. The moat isn't the storefront, the commitment-commerce mechanics, or the resell network (Shopify has that) — it's the **cross-maker identity-and-attribution layer**, the one asset an island-based incumbent is fenced out of by its own positioning. ### Customer ownership, consent & martech "Own the customer" creates an obligation: consent has to be managed somewhere, and *where the source of truth lives* decides whether the promise is real or a disguised lock-in. The governing test: **if this maker left tomorrow, could they fully and lawfully market to their consented customers without ever touching the network again?** **Source of truth: the maker's own ESP — not the network.** For a maker's *own* marketing, the maker's ESP (Mailchimp, Klaviyo, …) is authoritative and the network is a thin integration layer. This is *more* sovereign and *simpler* than a network ledger, passes the leave-tomorrow test tautologically, and dissolves the orphaned-opt-out-link problem: the unsubscribe link resolves to the ESP's native hosted unsubscribe, which the maker keeps after departure. - The network captures email + per-type marketing consent at checkout and **pushes the subscriber to the maker's ESP**; the ESP owns everything after (compliant unsubscribe, suppression, deliverability). - Opt-outs happen in the ESP; the network **reflects them via the ESP's unsubscribe *webhooks*** (prefer webhooks to polling). The network is a connector, never an ESP. - **Imported pre-existing lists** then need no special handling — they live in the maker's ESP, naturally arm's-length from the network's records. **Two consent domains — only one belongs in the ESP.** *Maker-originating* marketing → the maker's ESP is authoritative. *Network-originating* communications (buyer feed, aggregate marketing emails below, follow notifications) are the network's own relationship with the buyer, governed by **network-communication consent** the network must own. Keep them strictly separate: **the network may never borrow a maker's ESP list for its own sends.** "Send A's curation to A's buyers" means *A's buyers who also opted into network email* — the overlap, never A's whole ESP list. **The cross-maker buyer dashboard is a thin cache + fan-out, not a ledger.** With consent scattered across N ESPs, the unified dashboard ("manage all my subscriptions," "opt out of all promotional across all makers") needs a **read cache** (webhook-synced reflection — explicitly *not* the source of truth) and **fan-out writes** into each maker's ESP. Per-*maker* full unsubscribe is easy everywhere; **per-*type* across makers is the fiddly part** (each ESP models promotional-vs-drop differently — groups/tags/interests/lists — so your normalized type taxonomy must map onto each). Every dashboard control writes per-maker (per-type) records; a buyer-level standing preference ("never promotional from anyone") acts as a *default that generates per-maker records as new consents form*, not a send-time global override. **Greenfield fork: no ESP → network light-sending is the temporary source of truth.** Greenfield makers (the two interviewed) have no ESP, so the network provides **optional light first-party sending**, where it *is* authoritative because no ESP exists. Keep it deliberately minimal (never a Klaviyo competitor) and **exportable to seed a real ESP later**. The graduation path is the right shape: greenfield → grows → adopts an ESP → the network steps *back* from authority to integration. Network involvement *shrinks* as the maker matures. ### The network marketing channel (aggregate emails & email-embedded curation) Distinct from maker-originating ESP email, the network runs its **own** marketing channel — a discovery engine, provided it obeys the feed discipline. - **Personalized aggregate emails.** The network emails buyers (on the **network's** consent list) digests aggregating content/deals from *multiple* makers. The hard rule that keeps this from becoming retail-media-by-email: **content traces to the buyer's own engagement graph** — drops/deals from makers they follow, plus those makers' Curated-By picks — and the network *aggregates, personalizes, and delivers* (pipe) but **never injects platform-chosen merchants or sells placement.** Maker-as-discovery-engine, platform-as-pipe. - **Two-sided opt-out, both network-owned:** buyers opt out of receiving network marketing; makers opt out of being *included* in it. - **Curation as living discovery.** A buyer who engaged with Maker A can receive A's *current* Curated-By picks in their network digest, and as A's curation evolves the fresh picks flow into emails to A's (network-consented) buyers — turning Curated-By into a *recurring* discovery surface for the makers A vouches for, through the channel the network legitimately owns. - **Curated-By as an email widget in the maker's own ESP.** Makers embed their live Curated-By block in their own newsletters, with links carrying the stateless referral token — so a maker's own newsletter becomes a referral-generating surface (they earn credit; attribution works without identity). Points only to verified makers on controllable storefronts; reputation-staked, not paid; and — since email can't run JS — the widget is a send-time-pulled HTML block or a server-rendered image (refreshed per send). ### Verification: the gate to the trust tier Verification sits at the boundary between the commodity layer and the moat layer. Three states, not two: - **Unverified → full SaaS, zero network.** Any maker gets the complete commitment-commerce storefront (drops, pre-orders, clubs, own processor) — a paying customer of a genuinely good tool, but in *nothing* trust-gated (no referrals, no Curated-By either direction, no buyer feed, no agent feed). The storefront is commodity; gating it would suppress the Phase-1 wedge. Let everyone in the front door — *once the membership gate has loosened to open signup* (the phasing note below; at launch the door itself is invitation-only). - **Verified → eligible** for referrals, Curated-By, buyer feed, and agent feed — eligibility, not automatic inclusion. - **One gate, then independent switches.** Verification is the single floor; the channel opt-ins (network, agent) are independent choices within it. **Curated-By and referrals are verified-only in *both* directions** — a verified maker's stake can't vouch for unverified supply, so an unverified maker can be neither curator nor target. (A useful forcing function toward verifying.) **Network opt-in and agent (ACP) opt-in are independent siblings over one shared verified catalog — don't gate agents behind network membership.** A sovereign maker may refuse the maker-to-maker network yet *want* agent reach (net-new, sovereignty-neutral demand). **Verification — not network membership — is the precondition for the agent feed**, so the agent feed inherits the differentiator automatically ("*verified* products for agents," the structured trustworthy supply agents can't scrape). **Default agent inclusion ON (opt-out) for verified makers**: it maximizes the supply density that is your leverage with agents, and it's safe because agent sales route back through the maker as MoR. The agent feed is the **net-new-demand hedge** against the buyer feed's deliberate reach-weakness — the feed *deepens* existing follow graphs, agents *reach* outside them. **Verification is aspirational, not punitive — by design.** Because it gates the *demand* (referrals, feed, agents), not the *tool*, makers are pulled toward verifying rather than blocked at signup, and the unverified SaaS tier becomes a **verification funnel** (already paying, catalog in-system, upgrade = "verify → unlock demand"). It also keeps the trust guarantee **absolute**: both consumer-facing surfaces are hard-gated, so anything a buyer or agent sees is verified. **The membership gate itself phases — start closed, loosen toward open.** The three states above and the "front door / funnel" framing describe the **loosened end-state**. At **launch the gate is invitation-only, end to end**: there is no self-signup even for the unverified tool — every maker enters by invitation from an existing member who vouches they make original art or craft, rooted in a seed set Wiggleverse staff verify directly (the *originating edge*; full mechanics in the trust-&-safety section). Early scarcity is a feature: it lets word-of-mouth carry the beachhead, keeps the trust guarantee absolute while the rooted web is small, and makes every early edge high-intentionality. **Loosen toward open signup once roots and beachhead density exist** — then the unverified-tool front door opens, verification still gates the demand, and the funnel above kicks in at scale. This is the membership-gate analog of the peer-verification sequencing below (verify-makers-yourself-early → peer-verify-once-roots-exist): both start closed and open only as the trust web earns it. **Peer verification — the scaling mechanism.** Makers verify makers, staking reputation. It's *provenance verifying provenance* (real makers spot real makers), the web *is* a trust graph (harder to copy than a checkmark DB — it deepens the moat), and vouching doubles as community formation. **But it's the highest-stakes mechanism** — a Sybil/collusion surface that fails *catastrophically* (one polluted item in the "verified" feed breaks the guarantee). Build a *rooted, staked, multi-vouch trust web with a sampling audit*, never flat "anyone verified can verify anyone": - **Real, slashable stake** — a bad vouch costs the voucher (authority revoked, status reviewed), or "staked reputation" is a farmable click. - **Earned authority / time-trust gradient** — newly-verified can't immediately verify others, breaking ring-bootstrapping. - **Rooted graph** — anchor early verifications to a seed set *you* verified; every verified maker traces back to a root, so a compromised subtree can be found and revoked. - **Multiple independent vouches** for full status (ideally not all from one cluster). - **Sampling audit** (random + risk-triggered) so abuse is expensive and detectable, and **ring-pattern instrumentation** from day one. **Sequencing:** do *not* launch with peer verification. Verify makers yourself early (few enough for manual review, and you *need* to establish the root set). Enable peer verification once roots exist and volume makes manual review the bottleneck. Verification is now load-bearing in four places (referrals, Curated-By, buyer feed, agent feed), so throughput is a real growth governor — design the scaling path (tiered verification, community vouching as signal, provenance-documentation standards) early. ### Per-item provenance: the catalog's originality layer Verification answers a question about the *maker* (is this a real maker of original work?); provenance answers it about the *item* (is *this product* their original work?). A real maker's catalog is mixed — a potter sells their pots **and** resells pottery tools — and that is fine. What matters is that the buyer, and the trust surfaces, can always tell which is which. So every catalog item carries a **provenance classification** (metadata, like the cross-maker component layer below), **self-attested** by the maker, **audited** by the trust machinery, and **shown to the buyer**: - **Original** — the maker's own original art or craft (the pots). Purchased raw materials and supplies (clay, glaze, blanks) are inputs to *making*, not other-sourced components — a pot thrown from bought clay is original. - **Original + components (composite / kit)** — primarily the maker's work but incorporating identifiable parts from others; attributes each contributor (in-network Maker Y, or flagged where out-of-network). The kit / "partial" case, reusing the cross-maker component-metadata layer below. - **Resale — fellow Maker** — reselling another in-network maker's original item; provenance still traces to the true maker. (This is Curated-By / consignment expressed as a catalog item.) - **Resale — third-party / not original** — out-of-network commercial goods, tools, or supplies (the resold pottery tools). Honest, allowed, and clearly *not* original. Two rules ride on the classification: - **Buyer transparency is the point.** Every item shows its provenance badge — the consumer-facing expression of the moat: not merely "this maker is verified," but "this *item* is original / partly original / a resale / not original (and contains these makers' work)." It is the precise anti-Etsy signal — you always know what you're buying — and it *appreciates* as AI-generated and drop-shipped fakes proliferate. - **Trust-surface eligibility keys off it, per item.** Only **original** and **original-+-(in-network)-components** items are surfaced as the maker's original work in Curated-By / buyer feed / agent feed. A **fellow-Maker resale** may surface *attributed to the true maker* (that *is* Curated-By). **Third-party resale never enters a trust surface** — surfacing it would launder non-original goods through a trusted face (the Etsy-pollution failure mode, from the inside). A composite that contains any non-original component is flagged as such wherever it appears. The hard, still-open part is the **line between making and reselling** — finishing, assembling, and kitting sit in between (the standard to write, §12 #8): purchased supplies don't taint "original," but assembling mostly-third-party parts isn't original either. Misclassifying a resale as "original" is a provenance lie → a verification-revocation trigger (trust & safety, §10). Self-attestation makes classifying cheap; the sampling audit plus buyer reporting make gaming it risky. ### Non-maker referrers: the verified taste-maker tier (Phase 2) Any website can join as a *referrer* — a taste-maker/curator (a hobby YouTuber, blogger, podcaster) who isn't a maker but has audience and taste. Financially low-risk (pay-on-conversion, no custody, no MoR, no inventory). The risk is to the **verification moat**, handled by the *same tiering as makers*: - **Unverified referrer (open tier).** Generates referral links to verified makers, earns on conversion, but is **not surfaced in any trust-dependent surface** — a traffic source, self-limiting (a bad one doesn't convert) and contained (can't touch trust surfaces). - **Verified taste-maker (trust tier).** A legitimate community voice verified as a *trusted curator* (not a maker), reputation-staked and slashable — badge, surfacing, loses status for shilling. Verification separates the genuine taste-maker (additive) from the affiliate-spam farm (corrosive). **The load-bearing guardrail: uniform, non-biddable referral rates.** A maker-curator's commission pull is counterbalanced by peer respect; a pure taste-maker's incentive is more purely the fee, so if makers could set different rates, taste-makers would chase the highest payer — retail media through the referrer door. A uniform rate means they feature on **taste, not who pays most.** Plus **disclosure/labeling** (distinguish a maker's peer vouch from a taste-maker's disclosed-affiliate pick; FTC-required anyway), **referrer-only/one-directional** (never a destination, never a maker-verifier), and the **no-walled-garden rule** still holds. **Why it's worth doing:** taste-makers are the **net-new-demand engine** the maker-only network is structurally weak at — a third source alongside maker-curation (deepens) and agents (reach), and the most community-native (a trusted human voice, not an algorithm). **Phase 2, and a marginal add — not a new crossing.** A pure referrer has no fees to offset, so they need **cashable payout** — the same Connect/mass-pay rail Phase 2 already builds for cashable maker wallets and kit pure-supplier payouts. Three consumers, one scoped crossing; the marginal cost is the verification tier + uniform rate, not new money plumbing. (Paying a taste-maker is a *payout* to an affiliate — principal-on-both-sides, two independent events — not consumer money transmission.) Reserve option: a marquee taste-maker can accrue a pending cashable balance in Phase 1, paid on rail launch — don't open generally. ### The buyer-facing feed (Phase 2+) — how the marketplace emerges A consumer surface (site/app + email) where buyers see followed makers' drops, "buy it again," and Curated-By from makers they follow. This is **how the marketplace *emerges*** from accumulated follows rather than launching cold into the curation-vs-liquidity graveyard (§5). **Core principle — discovery is delegated to makers the buyer chose, never performed by the platform.** Every recommendation traces to a follow the buyer initiated. The platform never originates a recommendation — no "you might also like," no algorithmic cross-maker surfacing, no house-promoted placement. **Maker-as-discovery-engine, platform-as-pipe** — the *inverse* of the Shop app. Three payoffs: it keeps you **out of the discovery war** (you never compete with Amazon/Google/agents on recommendation quality); it keeps the feed **non-threatening to sovereign makers** (no buyer sees a maker they didn't choose or that a followed maker didn't vouch for); and it preserves **curation integrity** (follow-gated, reputation-staked curation can't be gamed toward pollution like an engagement algorithm). **The deliberate tradeoff:** pure follow-gated discovery is intentionally *weaker at net-new demand* — it deepens the graph buyers already know but doesn't introduce makers outside it. Growth stays permanently "makers bring audiences and vouch," never "the platform surfaces new reach" (agents and taste-makers are the net-new hedges). The correct trade for this positioning, as long as it's chosen knowingly. Disciplines: **buyer-opt-in by nature** (doubling as cross-merchant data consent); lead with the safe end (buy-it-again → followed drops → curated-by); any move toward platform-originated/algorithmic discovery is a deliberate, opt-in-by-everyone, much-later decision. ### Storefront architecture & Shopify coexistence **Two layers, kept separate — the core architectural decision.** A *storefront layer* (per maker) sits under a *shared cross-maker network service* (the moat). Conflating them couples the moat to one storefront engine and to single-tenant boundaries. - **Storefront layer (per maker).** Either your **white-label storefront** (headless backend + themed frontend) or the maker's **existing Shopify store** (federated). Handles that maker's catalog, cart, checkout, orders, and own payment processor (MoR). - **Shared network service (cross-tenant — the moat).** Verification graph; **canonical catalog index** — *with a cross-maker component-metadata layer* ("this product contains a component made by Maker Y," the kit/BOM relationship expressed in the catalog itself); cross-maker identity/follow graph; **a complete per-maker order history** (every order since the maker joined — captured because referral/fee computation must see orders, and reused for the transparency below); referral/Curated-By attribution + fee/wallet ledger; buyer feed; agent/ACP feed. A standalone service with its own datastore, spanning *all* makers and federating over heterogeneous storefronts — deliberately **not** part of any storefront engine. **The canonical catalog index lives in the network service — not a Medusa "mega-store."** Every maker's catalog (Shopify via Admin API, your Medusa storefronts via their API, anything else via adapters) is transformed into one normalized, verified index that powers Curated-By, the feed, and agents. A Medusa instance is a *storefront* (cart, checkout, one MoR, sellable inventory); the network catalog is a read-optimized *index* of products that live and sell elsewhere. Pouring all makers into one Medusa instance would make a thing shaped like a store that must never behave like one, and couple the neutral network to one engine. Keep each storefront as the system of record; the network holds a normalized verified *projection* — which also keeps Shopify and Medusa products *co-equal sources*, not Shopify imports into a competitor-shaped container. **Cross-merchant order transparency — the positive-sum twin of the money-flow "no."** Because the network already sees every maker's orders (it must, to compute referrals) and knows which products contain other makers' components (the catalog metadata layer), it can hand each maker something no single-store tool can: **visibility into every order that touches their work anywhere in the network** — their item sold inside another maker's kit, a referral they sent that converted, a component of theirs moving through a partner's store. This is the grocery **scan-based / Direct-Store-Delivery** pattern: the supplier sees the sell-through and knows when to restock or re-engage, *without being the store*. It costs the network nothing to give (it already holds the data), it is **uniquely the network's to give** (only the cross-tenant vantage sees across stores — which deepens the moat), and it stays firmly on the right side of the line: **transparency and coordination are free; custody is not** (the kit-supplier notification in Appendix C.2 is one instance). One asset, three uses — the same order history powers the referral ledger, the network-health metrics (§12 #4), and this reporting. **Build the white-label storefront on a headless backend (Medusa recommended).** "Build the 20%, rent the 80%" in code: the headless backend (Medusa — Node/TS, modular, payment-agnostic, no per-order revenue share; alternatives Saleor, Vendure, Spree) supplies cart, catalog, orders, customers, fulfillment, BYO payment, and you add the commitment-commerce engine — **drops, pre-orders, clubs, raffle/queue — as custom backend modules.** Mental model: in Medusa, *modules are backend domain logic; the storefront is a separate frontend app* consuming the Store API. So **the storefront is not a module** — the commitment-commerce *features* are modules, the storefront is their client, and the network service above is neither (standalone). Multi-tenancy (one shared instance vs. per-maker instances) is decoupled from the moat because the network service is separate either way; for two pilots, a single instance + shared theme is plenty. **Shopify makers: federate, don't migrate.** The network is storefront-agnostic, so a Shopify maker keeps Shopify (their MoR/processor) and joins via two hooks: **catalog sync** (Admin API + product webhooks into the verified index → eligible for Curated-By/feed/agents) and **referral handoff + attribution** (the Curated-By link carries a signed token that rides in as a **cart attribute → order note_attribute**, read from the order webhook to bill B / credit A — no checkout customization, any plan). **Hybrid wedge:** evergreen catalog stays on Shopify; the maker uses your platform only for the commitment-commerce *events* Shopify handles badly. Migrate later only if earned. **Curated-By on Shopify** rides **one installed app** built on **theme app extensions** (not legacy ScriptTag): a draggable **app *block*** for the curator role (renders verified picks from your network service, links carry the token) and an **app *embed*** for the recipient role (reads `?ref=` on landing, writes it as a cart attribute → order note_attribute → `orders/create` webhook). The app is a thin client — curation, verification, and the ledger live in your network service. Optional app proxy for crawlable server-rendered sections. Because it rides cart attributes through native checkout, the *entire* loop — display and attribution — works on a stock Shopify store with no checkout access and no theme surgery. **Strategic payoff:** the storefront-agnostic network makes your addressable makers the *entire* Shopify/Etsy/standalone install base — reachable via federation, not just makers willing to switch storefronts. The storefront is the wedge for makers who want a better tool; the network is open to anyone who verifies and syncs a catalog. This de-risks the scariest adoption question ("will makers switch storefronts?") — they don't have to. (Caveats: Shopify APIs are partly rented land, but you're not dependent on them — one source among several; Shopify takes its cut on Shopify sales, fine, since you bill your fee separately via ACH.) **Admin surfaces — three, not two.** The *network* is one product with one admin for everyone; the *storefront* admin is Medusa's (your makers) or Shopify's (theirs). - **Storefront admin** — only for your Medusa makers (products, drops, orders, fulfillment); a Shopify maker uses Shopify's admin. - **Network admin (bespoke, universal)** — curation, referral earnings + wallet, verification status + peer-vouching, follow/feed participation, network + agent opt-ins. No home in either storefront engine because it's the cross-tenant moat layer. - **Billing/account (bespoke, universal)** — ACH mandate, fee tier, invoices, payment history. So everyone uses the bespoke network + billing admin; Medusa makers *additionally* get Medusa's storefront admin; Shopify makers get theirs from Shopify. Notes: **ACH is universal, not referral-specific** — every maker gives a debit mandate at onboarding (gate mandate-on-file as a precondition for referral eligibility, so a referral-only maker can't accrue an uncollectable fee). And **Shopify makers get a read-mostly catalog/sync/analytics view** — a trust surface: a mirror (not a second editor; Shopify stays system of record), sync health (a silently-broken sync makes products vanish from the feed), and **network analytics** uniquely yours to provide because only you see across stores ("Curated-By sent me $800 last month" does quiet retention work). **Build-ordering:** the bespoke network + billing + analytics admin is foundational and on the critical path for both populations from day one — even the two Medusa pilots need it the moment Curated-By and referrals exist. ### Business model: network is the product, storefront is an optional convenience Now that Medusa exists and the network federates over any storefront, *centering* on storefront hosting has weakened — three erosions: the storefront is the commodity layer; Medusa makes it cheap for everyone; federation means a maker doesn't *need* your storefront to be in the network. - **The network is the product and the value capture.** Charge for the network — referral take + subscription — **uniformly, whether a maker is on your storefront or Shopify.** Revenue must not depend on storefront adoption; that keeps you credibly neutral and makes TAM = *every* maker. - **The storefront is an optional, opt-in convenience — SaaS-priced, never GMV.** GMV-take would recreate channel conflict, tax makers for using your rails (making your storefront *worse* than self-hosted Medusa), and pull you back toward money-flow entanglements. Price it as a flat SaaS fee that covers cost. - **Three postures — reject the first.** *Don't* be a storefront company with a network (GMV fees, competing with Shopify on hosting — wrong center of gravity). *Do* be a network company that offers a storefront — the best-in-class native commitment-commerce experience for makers who want it or have nowhere else to be — as a wedge, not the business. **"Why not just point makers to Medusa Cloud?"** Because Medusa Cloud sells *hosted infrastructure to developers*; it doesn't give a maker a working drops-and-clubs storefront. You sell a **vertical, maker-ready commitment-commerce product** where Medusa is *invisible plumbing*. The entire gap between raw infrastructure and a working maker storefront is your product — pointing a maker to Medusa Cloud is like pointing them to AWS. Corollary: **don't position or price as a hosting company** ("Medusa Cloud + modules" drags you into competing on infra margins). Hosting is a cost you absorb; the vertical experience (and the network) is what you sell. **Partner / consultant network.** Implementation consultants (community-embedded especially) onboard the **high-touch tail** without you becoming a services business, doubling as community-aligned distribution and mirroring the partner ecosystems that grew Shopify and Medusa — a second flywheel you *enable* (certification, partner referral fees, a directory) but don't *staff*. Guardrails: keep the product **genuinely self-serve for the median maker** (if makers *need* a consultant for a basic store, the product failed and partners are masking it), and structure partners as **referral/implementation partners, not white-label resellers**, so they don't become the relationship-owner and disintermediate you. ### Entity structure & trust positioning: non-profit, transparent, volunteer-built The org is a **true non-profit (501(c)(3) or equivalent), radically transparent (open books), engineered by volunteers with LLM-accelerated development, not raising money or selling equity.** This converts the trust position from a *promise* into a *guarantee*, and it's funded-viable for a reason that's thematically exact: - **The cost structure that usually makes non-profit tech infeasible is the one LLMs just collapsed.** The primary cost center — engineering — has been deflated by the same force the venture exploits. The entity and the opportunity are the same bet pointed two ways. - **No fundraising removes the only strong argument against true non-profit** (a PBC/B-Corp hedge exists only to preserve VC/equity optionality — which here is the door makers fear, so foreclosing it is the point). - **The structure *enforces* the anti-Etsy promise.** A 501(c)(3) legally can't be sold or distribute profits — the strongest answer to "will you sell our trust for GMV?" "Bind with structure, not promises," realized in the entity itself. - **Radical transparency is the substrate of the verification moat.** Open books/governance let the community *verify the incorruptibility* of "verified handmade" rather than take it on faith — the mechanism, not a nice-to-have. **The risk moved, it didn't vanish:** apply the rigor you'd have spent on fundraising to **volunteer sustainability.** LLMs change the math but not the human dynamics (attrition, bus-factor). Separate what needs reliability (network service, ledger, verification) from what tolerates volunteer cadence (themes, nice-to-haves), and keep the critical core off bus-factor-one. Also watch the **"fragile" perception** with professional makers — non-profit + volunteer reads as *aligned* to commons-minded makers but possibly *might-fold* to those building a livelihood; transparency is the counter, and §8 should test whether it reads **safe** or **nervous**. ### Hosting: managed vs. self-host (and the pilot) **What you sell and where you host are independent** — makers never see the infrastructure, so hosting is a pure cost/ops choice, *reversible and invisible* because Medusa is portable. **Managed (e.g., Medusa Cloud) now** (your scarce resource is attention on product + network, not infra savings); **self-host at scale** (unit economics; don't couple margins to one vendor). Multi-tenancy interacts with hosting price (per-maker instances multiply managed per-instance pricing; a shared instance is different math) — negotiate as a *multi-instance platform customer*. **The network service is hosted separately, always** — that separation is what makes the hosting choice switchable. **The two-maker pilot:** self-host on **GCP — Cloud Run + Cloud SQL (Postgres)**. Cloud Run scales toward zero when idle (suits drop-spiky traffic) and avoids babysitting a cluster at n=2; the shared-instance cost is low tens of dollars/month. **Watch the drop-traffic spike** — a scheduled drop is a burst of concurrent buyers, exactly the load that embarrasses an under-provisioned instance, and a storefront falling over *during a drop* is the worst moment for maker trust; load-check before a real drop. On cost: pass-through or a flat fee is fine, but **treat cost recovery as trivial** — two happy pilot makers (your first verification roots and references) are worth far more than reconciling a small GCP invoice. Frame any charge as "covering pilot costs," not the product's pricing model. --- ## 8. Next step: maker discovery (do this before building the platform) Goal: verify whether the cross-merchant-identity conversion advantage (Shop Pay's lift) is a *real moat for these makers*, and whether you can build your own version — and, more broadly, whether the demand side exists. **Avoid the measurement trap.** Don't ask "how much value does Shop Pay give you" — makers can't see the conversion counterfactual, so answers are vibes. Shop Pay's lift comes from **cross-merchant identity recognition removing first-purchase friction**, so measure the driver: the revenue split between **repeat fans vs. first-time strangers**, and whether buyers **already have Shop Pay**. (Repeat-fan-heavy makers capture little of the network effect; viral/stranger-traffic makers capture a lot.) **Don't concede a false tradeoff.** "Lose conversion to gain alignment" assumes you can't have the lift — but a curated cross-promotion network *structurally generates* cross-merchant identity as a byproduct (your own niche-scoped Shop Pay equivalent). You can't offer it day one (cold-start), but it's a **year-three asset, not a launch feature.** Concede the *timeline*, not the moat. **Listen for (beyond what you ask):** where buyers come from today (traffic-mix tell); what they pay Shopify **all-in** vs. what they *think* (most underestimate — the gap is your opening); whether the value-alignment grievance is real willingness-to-switch or venting; whether they'd want shared buyer recognition or guard their list; and — the asset they'll least volunteer — **whether they have an audience they'd bring** (a maker with no audience is a cost, not an asset). Also test whether the **non-profit/volunteer/transparent** framing reads as *safe* or *fragile*. **Weight what makers *do* over what they *say*.** "I'd switch for alignment and lower fees" is cheap and constantly contradicted by behavior (people stay on Etsy they openly resent). The makers worth building for already maintain a second channel, already *moved* on something, already bring their own buyers. **Interview log — early signal (2 greenfield makers, no existing site).** Liked *quickly spinning up an in-network storefront* (a network subdomain, not a dedicated domain) over a standalone site — confirming the greenfield on-ramp and the in-network address as a *preferred default*. Both conditioned it on *owning the customer*, which probing clarified means **usage-rights** (market to them directly, use/export the list, on or off the network) — the sovereignty principle reinvented unprompted. **Two cautions:** (1) the weakest evidence tier (liking an idea ≠ adopting ≠ paying ≠ staying) — chase the *behavioral* next step (real catalog in, a real drop, a referral); (2) it validates the *supply/storefront-convenience* (commodity) layer only — the **demand/curation moat is still untested** (do they have audiences, would they vouch, would they want to be vouched-for?). The network layer remains the load-bearing unknown. --- ## 9. Decision gates Gate the real platform build on evidence, not enthusiasm: - Do the first makers **refer you** to others? - Is the **pain consistent** across makers (the same 20%)? - Do target makers **have audiences**? - Can you reach roughly a **dozen makers** who want the same thing? Two makers justify a thoughtful, portable data model. They do not justify a platform. Build the data layer and the vertical primitives now; gate everything else on the dozen. --- ## 10. Trust & safety & maker accountability (reserved) *Reserved for the trust-&-safety write-up — the next major section, and §11's sibling: the two operational sections the architectural body of the memo had only gestured at.* The **shape** of post-verification maker accountability was already settled (originating-edge invitation graph; reputation flowing *up* that edge, decayed per-hop and hop-capped; consequence = a low, buyer-visible reputation score + loss of all network benefit rather than expulsion; inviter-held suspend/expel authority with a platform floor for active buyer harm and a governance appeal path) — that shape, with the still-open items, lives in §12 #1. What remains is the **reputation engine itself**, which is explicitly **OHM-guided work** (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)): scoring, the decay-coefficient and hop-cap values, how good standing accrues, display, benefit-gating thresholds, and how *harm* and *recourse* are operationalized all turn on OHM concepts (**reputation, trust, harm, recourse, value, dignity**) — defer to the relevant RFCs and cite them, proposing them where undefined. Holding the §10 slot keeps the section numbering stable for that write-up. --- ## 11. Legal & compliance The memo's legal strategy is not a list of compliance chores bolted on at the end — **it is one architectural choice, viewed through a legal lens.** Staying out of the money flow (§7, "Money flow: stay out of it") was justified there as a financial-risk decision; its larger payoff is *legal*: a single structural fact — **the maker is merchant of record on the maker's own processor, and the network never touches buyer funds** — discharges obligations across three otherwise-separate regulatory categories at once. **No money transmission. No marketplace-facilitator tax duty. No merchant-of-record liability.** Where a competitor that sits in the flow must license, collect, remit, and indemnify, the network simply isn't the regulated party. The genuine open exposures are exactly the ones that *aren't* dissolved by the money-flow stance — and the discipline of this section is to separate the two: what the architecture already answers (recap, hold the line) from what it doesn't (engineer down, or flag for counsel). **Convention: flag and verify — not legal advice.** Everything below is the *engineering posture* — the structural choices that keep the regulatory surface small, and the questions worth putting to specialist counsel. It is not legal advice; each item names what to verify and with whom. Where a principle turns on a load-bearing concept — *consent, harm, recourse, value, dignity* — it defers to the [Open Human Model](https://rfc.wiggleverse.org/p/ohm/c/default/) per the top-of-file note (handbook §4.4): cite the RFC, don't coin a local meaning. ### Money transmission (MTL) — recap from §7 Out of the flow → **none.** Holding customer funds (escrow, a balance, a payout you control) triggers state-by-state money-transmitter licensing in the US — the single most expensive licensing regime a small org could wander into. The network never holds buyer funds: the maker is MoR on the maker's own processor, and the platform fee is billed in arrears via ACH/invoice (§7, "How the platform gets paid"), which is the network charging *its own customer for software*, not transmitting a third party's money. - **The cashable Phase-2 rail rents a licensed transmitter — it doesn't become one.** When cashable payouts arrive (maker wallet cash-out, kit pure-supplier settlement, taste-maker affiliate payout — §7), the money moves over a BaaS rail (Stripe Connect/Treasury, Dwolla, a mass-pay provider) whose operator *is* the licensed money transmitter. The network is a platform user of that rail, not the regulated transmitter — the "rent the licensed infra, don't build it" move applied to compliance. - **The non-cashable wallet is not stored value.** The fee-offset wallet (§7) credits a maker against *future platform fees* — a discount / accounts-receivable entry, not a balance the maker can withdraw or spend with third parties. It is therefore neither stored value, a prepaid-access instrument, nor transmittable money, and stays outside the MT and stored-value regimes by construction. **Cashing out is the deliberate crossing** that re-opens the door — which is precisely why it is gated to Phase 2 behind a rented transmitter, never a toggle. *(Verify the wallet's non-cashable design against your states' stored-value / prepaid-access definitions before launch.)* ### Marketplace-facilitator sales tax — the centerpiece This is the high-consequence area the memo had entirely missing, and the one most likely to surprise. Post-*Wayfair*, every US state with a sales tax has enacted **marketplace-facilitator statutes** that can attach a *tax-collection-and-remittance duty* to a "marketplace facilitator" **even when it is not the merchant of record** — the whole point of these statutes was to make the platform, not thousands of small sellers, the collection point. So "the maker is MoR" does **not**, by itself, settle it; facilitator status turns on a separate test. **The two-part conjunctive test.** In most states (modeled on the SSUTA / MTC definition) you are a marketplace facilitator only if you do **both**: **(prong 1)** list, advertise, or otherwise facilitate the sale of a marketplace seller's products, **and** **(prong 2)** directly or indirectly **collect the payment** from the purchaser and transmit it to the seller. Both prongs are required — it is conjunctive, not "either." - **The referral-handoff model (§7, Model A) fails prong 2 — by design.** Checkout happens entirely on Maker B's own store and processor; the network passes a signed referral token, then bills B a fee and credits A — money on which the network is *principal* (its own fee revenue, its own credit), never buyer payment it collects and forwards. It arguably satisfies prong 1 (it facilitates discovery) but **cannot satisfy prong 2**, so it is not a facilitator. Many statutes reinforce this with an explicit **advertising-only / referral exclusion**: a person who merely advertises or lists products and refers purchasers to the seller, *without processing the payment*, is carved out by name. The referral network sits squarely inside that exclusion — which is *why* it is a referral network and not a checkout. - **The fragile edge is "indirectly collects payment."** Prong 2's "indirectly" is the word that does the damage: some statutes read it broadly enough to sweep in arrangements where the platform touches the payment flow even lightly (routing, splitting, holding briefly). The referral handoff is safe because it touches **zero** payment flow — but the margin of safety is "we never touch the money," not "we're small." The moment any feature lets the network touch buyer payment, the edge moves. - **Danger zones — where prong 2 attaches and facilitator status flips on:** - **Phase-3 shared checkout (§7).** A unified cart where the *network* collects the buyer's payment and routes/splits it to makers directly collects payment — prong 2 satisfied, facilitator duty attaches. This is exactly the "much later, optional, opt-in" crossing the phasing reserves, and **it carries a sales-tax-collection obligation as a first-class consequence**, not an afterthought. - **Split-payment kits (Appendix C, Model 3 — Connect destination charges).** One checkout auto-splitting to N connected accounts has the platform *indirectly collecting and transmitting* — facilitator. One more reason Model 3 is "avoid until you choose to be marketplace-of-record for kits." - **Connect destination/separate charges or `application_fee` where the platform is MoR.** The §7 charge-type dial that flips MoR to the platform *also* flips facilitator status, because platform-MoR means the platform is indirectly collecting the buyer's payment. The Connect setting is, again, a legal-posture decision (next). - **Tax calculation belongs to the maker's storefront layer — never the network.** Sales-tax *calculation, collection, and remittance* is the MoR's job, and the MoR is the maker. Both storefront engines do it natively (Shopify Tax; Medusa's tax module) and both integrate the specialist engines (Avalara, TaxJar) for nexus-aware rates and filing. The network must **not** build tax-calc — doing so would quietly adopt the very duty the architecture declines, and would invite the argument that a thing computing sales tax across makers is behaving like a facilitator. The network computes *its own* fees; the storefront computes the buyer's tax. *(Confirm facilitator status per state with a SALT attorney before any feature that touches buyer payment — especially before Phase 3.)* ### Stripe Connect configuration as legal posture — see §7 The Connect configuration is the hinge on which MTL, facilitator status, *and* merchant-of-record liability all turn, and it is **already specified in §7** ("Money flow"): the stance holds **only at Standard accounts + direct charges + `application_fee`** — maker stays MoR, disputes stay on the maker's balance, the network skims a fee without entering the flow. Destination / separate-charges-and-transfers and Express/Custom accounts each flip one or more of those properties (MoR → platform, dispute liability → platform, indirectly-collecting → true → facilitator). This section only records *why* §7's setting is a legal constraint and not an implementation detail; the dial itself is governed there. **Do not re-decide it here — cross-reference and hold the line.** ### Raffle / lottery — engineer out the consideration The raffle drop is the one primitive (§4) with direct **gambling-law** exposure. A lottery is three elements, **conjunctive: prize + chance + consideration.** Remove any one and it is not a lottery — so the design removes the controllable one. - **Free-entry allocation removes *consideration*.** The default raffle/queue mechanic allocates a *right to buy* a scarce drop by random draw, with **free entry** — no payment to enter the draw; the winner then purchases at the normal price like any other buyer. With no consideration paid for the *chance*, there is no lottery: it is allocation of limited inventory by lot, not a paid gamble (the same shape as a "no purchase necessary" sweepstakes — the chance must be free). The OHM frame is *fairness/dignity* in allocation: a transparent, equal-chance draw for scarce goods, not pay-to-play. - **Paid-entry raffle is off by default, pending per-state clearance.** A raffle where the buyer *pays to enter a draw for a prize* re-adds consideration and is a regulated raffle/lottery — generally unlawful for a commercial entity, lawful only for licensed nonprofits in some states, banned or tightly restricted (registration, caps, reporting) in others. It ships **disabled by default**, gated behind explicit per-state legal clearance. *Note the cross-current:* the 501(c)(3) entity (§7) may actually *open* charitable-raffle paths a commercial operator can't use — but that is a flag for counsel and a deliberate per-state opt-in, **not** a green light to turn paid raffles on. *(Verify per state — gambling / charitable-gaming law is among the most locally variable regimes there is.)* ### Consumer protection / FTC Three distinct FTC-adjacent duties: two fall on the maker (the seller / MoR) with the platform easing compliance, one the platform's own architecture already discharges. - **Affiliate disclosure (maker's + referrer's duty; platform surfaces it).** The verified-taste-maker tier and any compensated curation must carry clear, conspicuous affiliate disclosure (FTC endorsement guides, 16 CFR 255) — already required by the §7 taste-maker guardrails. The platform's job is to **make disclosure automatic in the UX**: label a disclosed-affiliate pick distinctly from a maker's reputation-staked peer vouch (reciprocal/reputational, not cash-compensated), so the buyer can tell sincere vouch from paid referral. Honest labeling here is a moat property, not just a rule — the whole anti-retail-media stance depends on the buyer seeing the difference. - **The pre-order / 30-day delivery rule (maker's duty; platform UX eases it).** Commitment commerce *is* taking money before delivery, which squarely triggers the FTC **Mail, Internet, or Telephone Order Merchandise Rule** ("the 30-Day Rule"): the seller must ship within the stated time — or within 30 days if none is stated — and on delay must give the buyer notice and a right to cancel for a prompt refund. This is the **maker's** obligation (maker is seller / MoR), but the commitment-commerce engine is uniquely positioned to make compliance the path of least resistance: **require a stated fulfillment window** at drop/pre-order creation, surface it to the buyer at commit time, **prompt delay notices** when a window slips, and support one-click cancel/refund. Compliance-by-design as a product feature — the platform eases the duty without assuming it. (This is also the legal spine of the §12 #1 "verified maker collects pre-orders and ghosts" failure mode: the 30-Day Rule is what a ghosting maker *violates*, and the platform's notice/refund machinery is the buyer's first recourse before any chargeback.) - **Handmade-claim substantiation (platform architecture already answers it).** "Handmade," "original," "made by this person" are advertising claims subject to FTC substantiation; an unsubstantiated claim is a deceptive practice. The **per-item provenance system (§7) *is* the substantiation mechanism** — self-attested classification, audited by the sampling audit + buyer reporting, shown as a buyer-visible badge, with misclassification a verification-revocation trigger. The trust architecture the moat already requires doubles, exactly, as claim-substantiation infrastructure — a place where the product-defining feature and the compliance obligation are the same build. (OHM *value* / *dignity*: the truthfulness of "handmade" is a value claim about the maker's work, which is why it is load-bearing both legally and morally.) ### Privacy Recap the §7 consent architecture, now read as the privacy-law posture. - **Two consent domains, two consent layers, source-of-truth in the maker's ESP.** Maker-originating marketing lives in the maker's ESP (authoritative); network-originating communication consent the network owns; the maker decides store participation and the buyer decides cross-network recognition (§7, "Customer ownership, consent & martech"). This separation isn't only good product design — it is what keeps each personal-data flow attributable to a lawful basis and a controller. - **DPAs.** Where the network processes personal data on a maker's behalf (catalog sync, ESP push, the dashboard cache, the buyer feed) it acts as a **processor** and needs **Data Processing Agreements** with makers, plus back-to-back DPAs with its own sub-processors (ESP, hosting, the Connect/BaaS rail). Stand the DPA chain up at onboarding, not after a buyer asks. - **Build to the strictest state law, not a 50-state matrix.** Rather than tracking divergent regimes feature-by-feature, build to the **strictest common denominator** — CCPA/CPRA plus the newer comprehensive state laws (and GDPR the moment EU buyers appear) — and apply it everywhere: real consent capture, access/deletion rights, opt-out of "sale/sharing." The cross-maker identity graph is the privacy-sensitive surface, and it is **opt-in by design** (§7) — so the architecture is *already* aligned with the strictest "no sharing without affirmative consent" reading, rather than retrofitting opt-outs onto a default-share. The OHM *consent* RFC is canonical for what "consent" must mean across these surfaces — cite it; don't re-derive a local definition. ### Freedom-to-operate / patent - **Low-novelty mechanics → low patent-thicket risk.** The commitment-commerce primitives (scheduled drops, pre-orders/deposits, raffle-as-allocation, clubs/memberships, referral links, cross-merchant attribution) are widely practiced, decades-deep mechanics with abundant prior art. The novelty is in the *combination and positioning*, not in any patentable mechanism — so the risk of a blocking patent thicket over the core build is low. - **Do a basic FTO check anyway.** Before building a headline feature, run a basic freedom-to-operate search — particularly for anything resembling a specifically-patented method (one-click-style checkout flows, specific loyalty/attribution or pledge-management methods). Cheap insurance against the rare narrow patent; not a reason for alarm. - **Transparency doubles as defensive prior art.** The radically-transparent / open-books posture (§7 entity) means the design is *published as it is built* — which is **defensive publication**: dated prior art that makes it harder for anyone (including a well-funded incumbent) to later patent the combination and assert it against you. The transparency that serves the verification moat pays a second dividend in patent defense — one posture, two protections. ### Novelty / competitive finding *(Restored — this finding didn't survive the generalization from the miniatures memo and belongs here.)* The honest competitive read: **the components all already exist** — cross-merchant inclusion (Shopify Collective, Carro), pre-order/drop tooling, affiliate/referral networks, verification badges, non-profit governance — but the **specific combination is novel and unproven**: verified per-item provenance + reputation-staked cross-maker referral + native commitment-commerce + non-profit/transparent governance, scoped to one dense vertical. **The moat is positioning and governance, not patents.** Do not expect IP to defend the position; expect the defense to be community standing, the rooted trust graph (§7 verification), the no-walled-garden value rule (Appendix D), and a 501(c)(3) structure a commission-optimized incumbent structurally cannot copy without betraying its own customers (§7, "Why this is the defensible core"). This is the same truth the spine states — *the components exist; the combination is novel but unproven* — carried into the legal lens: novelty here buys no monopoly, so the work is to make the *combination* hard to replicate by other means. ### Entity structure / UBIT - **The 501(c)(3) path** (§7, "Entity structure & trust positioning"): a true non-profit that legally cannot be sold or distribute profits — which is what converts the anti-Etsy promise from a pledge into a structural guarantee. The legal work here is *formation*: exempt-purpose drafting, governance documents, state charitable registration. - **The UBIT tension — flag for nonprofit counsel.** A 501(c)(3) that earns **platform fees and referral fees** is earning income from a trade or business regularly carried on — which raises **Unrelated Business Income Tax (UBIT)**. The crux is whether that fee income is *substantially related* to the exempt purpose (e.g. sustaining independent makers / a charitable-educational mission) or is merely a commercial activity that happens to fund it. Get it wrong and the exposure ranges from UBIT liability on the fee revenue to — if commercial activity comes to *dominate* — jeopardy to the exemption itself. This is the **one place the non-profit choice creates legal complexity rather than dissolving it** (the mirror image of the money-flow stance, which dissolves complexity), and it is genuinely unsettled at this memo's altitude — so it is an early, explicit **flag for specialist nonprofit/tax counsel**, who may reshape the exempt-purpose framing, structure the fee-earning activity to stay "related," or recommend a taxable subsidiary for the commercial layer. Surface it in §8/§9 diligence rather than discovering it post-formation. **The through-line, restated.** The pattern of this whole section is one shape: **where the architecture stays out of the money flow, the legal burden largely dissolves** — MTL, marketplace-facilitator tax, and MoR liability are all discharged by the single choice that the maker, on the maker's own processor, is merchant of record. What remains are the exposures that *aren't* a money-flow question — and each gets handled in kind: **engineer it down** (consideration out of the raffle; compliance-by-design pre-order UX; provenance-as-substantiation; opt-in privacy aligned to the strictest law) or **flag it for counsel** (UBIT, paid-entry raffles, per-state facilitator confirmation before Phase 3). The legal strategy is not separate from the architecture — **it is the architecture, audited.** *Flag and verify — not legal advice.* --- ## 12. Open sections to develop (backlog) This memo is deep on the architectural/strategic axes (money flow, network mechanics, moat theory, consent) and thin on several operational ones that matter as much or more. The gaps cluster on the un-fun, operational side — which is usually where ventures actually die. Each below is a separate future session. Rough priority order; recommended next is #1. 1. **Trust & safety / maker accountability (post-verification) — shape decided; §10 now reserves the section slot; reputation *engine* is OHM-guided work.** Verification is only an *entry* gate; the question is what happens when a maker behaves badly afterward. Commitment commerce makes this the signature failure mode — "verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, not an edge case — and the money-flow stance solved the *financial* exposure (maker is MoR) but not the *reputational* one, which is the one the moat rests on. **The shape we settled:** - **Originating edge.** Every maker enters by invitation = a vouch they make original art or craft, rooted in a staff-verified seed set — a permanent graph topology (the membership gate starts invitation-only and loosens over time, §7). - **Inviting doesn't pay** — the incentive is the commercial relationship, never a bounty (which would manufacture Sybil incentives). - **Reputation flows up the originating edge** — transitive but **decayed (a per-hop coefficient) and hop-capped**, so impact is strong next to the misbehavior (a prompt-to-act for whoever can act) and negligible by ~6 degrees out. Framed as **positive reinforcement** (earn/grow standing), not punishment. - **Consequence = a low, buyer-visible reputation score + loss of all network benefit (Curated-By, feed, referrals, agents) — not expulsion.** The maker keeps the storefront/tool, loses amplification, and wears a score buyers can act on (transparency as enforcement; keeps trust surfaces clean by construction). This is a *member in bad standing*, **not model "a"** — at launch every storefront holder was invited. - **Inviter holds primary suspend/expel authority** over their sub-graph, with a **platform floor for active buyer harm** and a **governance appeal path** (#7); expulsion is the rare extreme. Misclassifying provenance is a trust violation (§7 per-item provenance). **Still to flesh out — explicitly OHM-guided (handbook §4.4, [OHM](https://rfc.wiggleverse.org/p/ohm/c/default/)):** the reputation *system* itself — scoring, the coefficient/hop-cap values, how good standing accrues, display, benefit-gating thresholds, and how *harm* and *recourse* are operationalized — turns on OHM concepts (**reputation, trust, harm, recourse, value, dignity**); defer to the relevant RFCs and cite them, proposing them where undefined. Also still open from the original scope: verification-revocation triggers/process (non-delivery pattern, inauthentic goods, non-response), the buyer-harm/dispute framework, non-delivery handling given you're out of the flow (chargeback-via-maker-MoR + transparency, not guarantor), and false-report/collusion controls. 2. **Demand strategy / buyer-side go-to-market — the keystone, currently only *admitted* as a risk.** The doc names "demand is the unvalidated keystone" repeatedly but never attempts a plan; everything concrete is supply-side. Needs: a crisp *buyer-side* value proposition (why a buyer shows up and comes back, stated as its own thing); a first-100 / first-1,000-buyers plan; a content/community/SEO posture for the buyer side; and a §8 extension that tests buyer demand, not just supply. Naming the risk ≠ grappling with it. 3. **Legal & compliance, consolidated — done this session (now §11).** The scattered legal points are consolidated in **§11 (Legal & compliance)**, with the out-of-money-flow stance framed as the legal strategy itself: MTL recap, the marketplace-facilitator sales-tax analysis (the centerpiece — two-part conjunctive test, the referral exclusion, the "indirectly collects" edge, the Phase-3 / split-payment-kit / Connect danger zones, and tax-calc as the storefront's job), the Connect-config legal posture (cross-ref §7), raffle/lottery (engineer out *consideration*), FTC / consumer-protection (affiliate disclosure, the pre-order 30-day rule, handmade-claim substantiation), privacy / DPAs, freedom-to-operate, the restored novelty finding, and the entity / UBIT flag. 4. **Sustainability economics & health metrics — there are no numbers anywhere.** "Non-profit" doesn't mean "needn't cover its costs." Needs: a back-of-envelope unit-economics model (does referral take + network subscription cover the network service + verification labor + hosting at N makers / X GMV?); and a North Star + network-health/liquidity metrics (% of GMV that's cross-maker-referred, follower growth, drop sell-through, repeat-buyer rate). The §9 gates are all qualitative. 5. **Concrete MVP scope / build roadmap.** The phasing is *conceptual* (Phase 1/2/2+/3); there's no literal "v1 ships these features, in this order." Given volunteer capacity is the stated single point of failure, scope discipline is existential — define the minimum lovable build. 6. **The data model (sketch the entities).** Named as the load-bearing portable asset ("cheap now, expensive to retrofit") and referenced everywhere (canonical catalog index, variant/kit BOM, referral ledger, consent records, verification graph, follow graph) but never drawn. Deserves at least an entity diagram. (May already exist in prior schema work — if so, this is a pointer, not net-new.) 7. **Governance, concretely.** The non-profit's trust rests on governance that's been floated ("open governance / maker council") but never specified: who sets and changes verification standards, board/maker representation, and how disputes about *the network itself* resolve. 8. **Hybrid makers — the making-vs-reselling line (standard).** *Direction set:* provenance attaches **per-item, not per-maker**, via a self-attested, buyer-facing catalog classification (Original / Original + components / Resale – fellow Maker / Resale – third-party), with trust-surface eligibility keyed to it — see §7 "Per-item provenance: the catalog's originality layer." *Still open:* the precise, **auditable line between making and reselling** — purchased supplies don't taint "original," but where exactly do finishing, assembling, and kitting fall? — plus the enforcement/audit hook (ties to #1 accountability) and the exact buyer-facing label wording. Interacts with the consignment/resale "avoid" fork (§7) and the no-walled-garden value rule (Appendix D). --- ## Appendix A — Choosing a beachhead vertical (and sequencing expansion) The platform serves makers in general, but it must *launch* into one dense community. This is the selection method, with miniatures as the worked candidate. **The filter.** Score candidate communities on: made-to-order/drop motion; non-fungible inventory; hybrid digital + physical; recurring drops; variant explosion; audience-having makers; authenticity grievance; scalper/counterfeit problem; a reachable community hub. The recurring finding across verticals: the storefront/build layer is already commoditized (Shopify, Fourthwall), so the prize is the **demand-aggregation / curation layer** (flow). The right target is a vertical where that layer is *unoccupied* and you can belong to the community. **Worked example — miniatures as the beachhead.** Miniatures express every form of the commit-then-make primitive at once: recurring monthly STL/digital releases (Patreon / Cults3D model), digital delivery with licensing, *and* physical resin/metal casting that's pre-order or made-to-order, plus heavy variant explosions (scale, material, painted/unpainted) and army-builder bundles. That membership + digital + physical-preorder combination is exactly where Shopify is mediocre. The expansion scan: | Vertical | Pros | Cons | Flow layer | Adjacent to minis? | Verdict | |---|---|---|---|---|---| | **Resin dice** | Drop culture is the *default* motion; large maker audiences; vivid authenticity grievance (cast-copies undercutting real casters); active scalper market makes queue/anti-flip valuable; drop/queue/commission infra **unserved**. | Lower price points; casting is labor-intensive; design-theft enforcement complexity. | **Open.** | **Yes — same tabletop buyer.** | **Top pick / first expansion.** Reuse minis' made-to-order/pre-order/variant/provenance primitives; add drop-scheduling, queue/raffle, anti-scalper as net-new. Compounds community density, no second cold-start. | | **STL / digital files** | Shares minis' digital gnarl (tiered licensing, membership drops, re-upload piracy where provenance defends); huge audience. | Most contested and **consolidating** — MyMiniFactory bought Thingiverse; Cults3D, Patreon, MakerWorld entrenched. | **Owned.** | Yes (minis' digital half). | **Partner/coexist; don't build.** Own the physical + storefront + cross-maker network it doesn't touch. | | **Hand-dyed yarn** | Non-fungible inventory (dye lots); dyed-to-order pre-orders; yarn clubs = subscription drops; variant explosion; tight community (Ravelry + IG); strong anti-mass ethos. | Shopify + apps cover the storefront; **a curated demand-aggregator already exists (Indie Untangled)**; non-adjacent buyer = full second cold-start. | **Partly owned.** | No. | **Strong-but-contested; validate first.** Best "wide" option, but probe whether the incumbent has *earned* switching-cost loyalty or merely lightly occupies the niche. | | **Custom knives** | High value/unit; waitlist/lottery/deposit by default; secondary market makes queue integrity valuable; collector culture. | **Entrenched decades-old curated marketplaces own the flow** (Arizona Custom Knives, Noblie); blade-shipping regulatory drag; non-adjacent buyer. | **Owned.** | No. | **Deprioritize.** Dislodging earned loyalty *plus* weapons-shipping compliance. | | **Enamel pins** | Large audiences; campaign/pre-order motion; LE secondary market; B-grade sub-market. | Largely **design+manufacture (POD), not craft**; grievance is art theft (originality), not handmade provenance; Fourthwall holds the creator-merch layer. | **Owned.** | No. | **Skip.** The product isn't really handmade, so a verified-*provenance* moat doesn't fit. | **Strategic conclusion — deep-and-adjacent over wide.** Dice wins on every axis *and* shares the buyer, so the arc is **beachhead → dice → broad physical tabletop** — one buyer, one community, one compounding set of drop-and-provenance primitives. Yarn/knives are "wide" bets into scenes where the flow layer is already held by an embedded member — the "don't fight where someone's embedded" trap. Of the wide options, only yarn merits a validation probe before being ruled out. --- ## Appendix B — The commitment-commerce layer: incumbents & the open gap "This feels Kickstarter-ish" is correct, and the incumbents are specific. The crowdfunding/pledge-management space is large, mature, and consolidating — but built for **episodic, project-scale campaigns**, not an individual maker's **continuous drop cadence.** That distinction is the entire opening. (The pattern: every incumbent started as the tool managing the gap between committed demand and delivery — pledge management — then grew up into the funding layer.) | Player | What it is | Built for | Relevance | |---|---|---|---| | **Kickstarter** | All-or-nothing campaign crowdfunding; no integrated pledge manager | Episodic, project-scale campaigns | The launchpad | | **Gamefound** | Tabletop-native; pledge-manager → full crowdfunding platform with late-pledge stores | Episodic tabletop campaigns + post-campaign stores | **Sitting in your adjacent vertical**; fast-growing, Kickstarter's biggest tabletop rival | | **BackerKit** | Pledge-manager (surveys/shipping/tax/add-ons) → also crowdfunding | Post-campaign fulfillment + campaigns | "Mission control" for fulfillment | **The open gap (where to play):** none of these serve the maker running a small drop every other Saturday, a monthly made-to-order club, or a 10-piece lottery. The unserved space is **continuous commitment-commerce cadence** — the recurring, relationship-driven, small-batch motion *between* Shopify (continuous but stock-only) and Kickstarter/Gamefound (commitment but episodic). The recurring strategic shape (the same as the rest of this memo): there's always an entrenched incumbent owning the *episodic/distribution* layer — Shopify (stock), MyMiniFactory (file distribution), Gamefound (campaigns) — and the open prize is the *continuous cross-maker relationship* layer they don't serve. **Coexist with the episodic incumbent; own the continuous demand-relationship network.** --- ## Appendix C — Composite multi-maker kits A kit combining products from multiple makers, sold as one SKU on a maker's storefront — the deepest expression of maker collaboration, a natural Curated-By extension, a strong "kit drop" — but it presses hardest on the one line the architecture defends: **custody of funds.** Two governing rules. For the kit creator: **be a *principal reseller* of the kit, never a *conduit* aggregating others' sales** (principal is a product; conduit is money transmission). For the platform: **coordination and bookkeeping are free; custody — funds resting in an account you control — is the line.** ### C.1 The retail model One charge means one merchant of record and one payout destination; "one SKU, N makers, money perfectly siloed" is a contradiction. | Model | Mechanism | Verdict | |---|---|---| | **1. Lead maker = MoR, others = suppliers** | A sells the kit as A's own SKU on A's processor; A owes X/Y wholesale COGS. A is a principal reseller (legitimate drop-ship/wholesale, **not** transmission). | **Recommended.** Single charge, single MoR, out of the consumer flow. The virtual-kit/BOM pattern with components from other makers. | | **2. Curated kit, no unified checkout** | Themed Curated-By bundle; each component hands off to its own store. | Free but weak — N transactions in a bundle costume; not a true SKU. | | **3. Facilitated split-payment** | One checkout, auto-split to N connected accounts (Connect destination charges) — Shopify Collective's mechanism. | Cleanest *experience*, but you become facilitator / in the flow. Avoid until you choose to be marketplace-of-record for kits. | Model 1 has two physical variants: **A assembles** (components ship to A, A builds + ships one box) or **A drop-ships** (X/Y ship directly; A is still MoR and still owes wholesale). C.6 is the decisive reason to prefer assembly. ### C.2 Supplier settlement — how A pays X and Y **Custody is the line:** the moment funds rest in an account you control and you pay them onward, you're a transmitter. "Facilitate without being in the flow" means facilitating the *coordination* (or netting on your own account as principal), never custody. **The default stance: the kit merchant (A) handles every supplier obligation; the platform moves no money at all.** A is MoR and a principal reseller, so A owes X and Y on whatever wholesale terms they agreed and **settles with them directly, off-platform**, the way any two businesses do. The platform's role is **transparency, not transfer**: it can *notify* a supplier when their item sells in someone else's kit ("your *Frostfang Drake* sold 3× in **Hearthforge**'s 'Winter Warband' kit"), so makers see their cross-maker pull — **without facilitating any payment between them.** Notification is pure coordination (free); routing a single dollar from A to X is custody (the line). This knowingly re-weighs the peer-to-peer friction below: accept the friction (notification softens it) to keep the platform *entirely* money-free. Models B and C are then **optional conveniences a maker may elect**, never the platform stepping into the flow. | Model | Mechanism | In the flow? | |---|---|---| | **A. Bookkeeper / peer-to-peer (default)** | Platform records the payable and *notifies* the supplier; A→X money moves directly, off-platform. | No — the cleanest; notification offsets the "makers chasing each other" friction. | | **B. Net through the existing fee ledger** | X's receivable → credit in X's fee-offset wallet; A's payable → charge on A's next invoice. Principal on both sides. | No — *for the non-cashable portion.* **Optional, maker-elected** (still cashless: a fee credit, not a transfer). | | **C. Connect direct payout** | Buyer pays A; platform routes component cost to X/Y connected accounts; Stripe is the transmitter. | Yes — scoped re-entry. **B2B-first is the safest place to cross** (verified, KYC'd, mandate-on-file makers). | **Supplier choice with a carrot:** beyond the money-free default (A), a supplier may elect **non-cashable wallet credit** (nets their own fees, out of flow) or **Connect payout** (real money, scoped in-flow), with a **bonus for wallet**. Caveat: wallet credit only helps a maker who *has fees to offset* — a **pure supplier** (supplies many kits, rarely sells) accrues trapped credit and needs Connect regardless. Plan for both. Phasing: Phase 1 = Models A/B (record + notify + net; settle the remainder peer-to-peer); Phase 2 = Model C for pure suppliers, on the shared cashable rail. ### C.3 Fee economics — taxed once Components carry a referral fee (supplier bears it, as in Curated-By) — but **tax each kit dollar once.** Example: kit retails at R; wholesale $40 (X) + $30 (Y) = $70 COGS to A. X's $40 → 15% = $6 platform, X nets $34; Y's $30 → 15% = $4.50, Y nets $25.50; A pays the standard platform fee on **A's own margin (R − $70)**, not the full R. Charging A's full fee on R *and* referral fees on the components would double-tax the $70. All of it runs through the ledger off the order event, never the consumer payment. ### C.4 Where kits can be sold — inventory integrity, not fees The fee/settlement machinery works on *any* storefront (computed from the order webhook + the kit BOM in your network service), so a **Shopify maker can sell a kit, be MoR, and have settlement run on the webhook.** What Shopify can't give is a **real-time cross-maker stock check at purchase** (you don't control its checkout), so finite-stock components risk a sync-lag oversell. Therefore: **finite-stock kits → favor your Medusa storefront** (you control checkout: atomic availability gate + atomic order+payable); **made-to-order kits → storefront-agnostic** (no finite-stock race; kit lead time = max of component leads = pre-order semantics). v1 scoping: launch kits as a Medusa-seller feature; optionally allow made-to-order kits for Shopify sellers; defer Shopify finite-stock kits. ### C.5 Wholesale bookkeeping — including volume tiers Storing "X charges A $W/unit, tiered by volume" and computing settlement from units is **pure facilitation (out of flow).** Two details tiers force: **retroactive vs. prospective** (when the price drops at unit 11, do 1–10 reprice or only 11+? — a *term A and X agree to*, which the platform stores and applies); and **stateful settlement** (tiered pricing depends on cumulative units, so settlement is a running total per supplier-agreement, not per-order-independent — build the ledger for that from the start). ### C.6 Shipping & fulfillment — the decisive argument for assembly A kit drop-shipped from N makers = **N shipments; shipping scales with maker count, not order** (≈3× for three makers). The premium lands somewhere and every option hurts: on the **buyer** (visible combined shipping — a conversion killer on a "deal" kit), **A** (uncontrollable margin variance), or **suppliers** (inflated COGS). Managing it, best to worst: **(1) assemble-and-consolidate (default)** — components ship to A, A packs one box; fixes three problems at once (single shipping cost, single-package experience, QC liability), at the cost of A doing micro-fulfillment (which *is* A's value, and justifies the margin); **(2) 3PL/hub consolidation** (defer — overkill at indie volume); **(3) honest drop-ship** ("ships in N packages," disclosed — reserve for when consolidation is impossible); **(4) shipping-smart kit construction** — surface estimated combined shipping *at kit-design time* and prefer same-region makers (your network sees cross-maker geography no single maker can). | Components | Fulfillment | Result | |---|---|---| | In-stock | Consolidate | One box, fast, clean — **best case** | | Made-to-order | Consolidate | One box, but kit lead = max(component leads) + assembly hold | | Made-to-order | Drop-ship | N boxes, N arrival times, N charges — **worst; avoid** | **Through-line:** shipping argues the kit creator should be a real **assembler-principal**, not a thin aggregator. The clean money model (principal reseller) and the clean shipping model (assemble-and-consolidate) point at the same role for A — the signal the design is coherent. --- ## Appendix D — Storefront control & network participation (why walled gardens are out) The gating property is **control of the three surfaces the network must touch**: the **storefront page** (to host the verified merchant referral collection), **checkout** (to attribute referrals and run clean agentic purchase), and the **buyer relationship** (to own identity). Merchant-controlled storefronts grant all three; walled-garden marketplaces deny all three *by design* — intermediating the buyer is the marketplace's business model, so participation **degrades monotonically as a maker cedes control to a walled garden.** Layered on top is a value rule stricter than the technical limits: **the network never routes buyers *into* a walled garden — not via Curated-By, the buyer feed, or the agent feed.** So walled-garden makers are **invitation targets, not destinations** — even where a marketplace's API would permit ingesting their catalog, the value rule forecloses surfacing it as a buyable destination. Legend: ✓ supported · ◐ partial/limited · ✗ not supported. | Provider | Catalog sync-in | Be a curator | Be a network destination | Clean referral-fee attribution | Owns buyer | Clean agentic checkout | |---|---|---|---|---|---|---| | **Your white-label (Medusa)** | ✓ native | ✓ you build the page | ✓ controllable + value-OK | ✓ you own checkout | ✓ maker owns relationship | ✓ you expose ACP | | **Self-hosted (Woo, Saleor, Vendure, custom)** | ✓ open APIs/plugins | ✓ full page control | ✓ controllable + value-OK | ✓ controls own checkout | ✓ owns buyer | ✓ their build exposes ACP | | **Shopify** | ✓ Admin API + webhooks | ✓ theme app-extension block | ✓ controllable + value-OK | ✓ cart attr → order webhook (any plan) | ✓ merchant owns customers | ✓ their processor | | **BigCommerce** | ✓ Catalog/Admin API | ✓ open storefront | ✓ controllable + value-OK | ✓ controls checkout | ✓ owns buyer | ✓ their processor | | **Squarespace / Wix** | ◐ commerce APIs (read) | ◐ code-injection, no clean app-block model | ✓ controllable, value-OK | ◐ checkout more closed — coupon/landing only | ✓ owns buyer | ◐ depends on platform | | **Etsy** | ◐ Open API v3 — *unused as a destination by value rule* | ✗ can't modify the page | ✗ **value rule** — invitation target only | ✗ Etsy owns checkout | ✗ Etsy owns the buyer | ✗ Etsy's decision | | **eBay** | ◐ APIs (read) — *unused* | ✗ can't modify the listing | ✗ value rule; invitation target | ✗ eBay owns checkout | ✗ eBay owns the buyer | ✗ eBay's decision | | **Amazon Handmade** | ✗ gated/restricted API | ✗ zero storefront control | ✗ value rule + Amazon owns all; invitation target | ✗ Amazon owns checkout | ✗ Amazon owns the buyer (most completely) | ✗ Amazon's own agents treat you as a competitor | The table's shape *is* the thesis: **controllable storefronts ✓ across; walled gardens ✗ across.** Not a coverage gap — a restatement of who the network is *for* (makers who own their commerce, or will) and what it's an alternative *to*. **The three-surfaces gate:** storefront-page control → be a curator; checkout control → attribution + agentic checkout; buyer-relationship control → identity/sovereignty. **Walled gardens are who you're an alternative to — not a gap to cover.** A maker deep in Amazon Handmade who can't participate is the person the pitch is *aimed at*, who hasn't left yet. The right move is **invitation, not integration**: "I'd feature your work the moment you own your commerce" — the absence of a link is the recruiting signal, making membership the price of inclusion rather than subsidizing captivity. Notes: Etsy is the *most permissive* walled garden (Open API v3, models made-to-order, runs an affiliate program) but the value rule forecloses using it as a buyable destination anyway; a maker on *both* Etsy and a controllable storefront participates via the controllable one. Amazon Handmade is the most walled and the most hostile (restricted API, total buyer ownership, its own agentic-commerce ambitions). The **verification inversion** becomes a recruiting message: "we'd vouch for your work — verified independent of any marketplace's compromised badge — the moment you own your commerce." --- ## Recurring principles (the spine) Every decision in this memo reduces to a few invariants worth stating once, plainly: - **The network is the moat; the storefront, hosting, and Medusa are fungible means in service of it.** - **Bind with structure, not promises** — non-cashable wallets, verification gates, sovereignty-by-policy, the non-profit entity, the no-walled-garden rule. The wrong path is foreclosed, not merely disavowed. - **Custody is the line; coordination and bookkeeping are free** — cross into the money flow once, knowingly, with rented infra (the Phase-2 cashable rail), never by accident. - **Maker-as-discovery-engine, platform-as-pipe** — discovery is delegated to makers the buyer chose, never platform-performed. - **Gate the demand, not the tool** — the storefront stays open to all; the network's *demand* surfaces (Curated-By, feed, referrals, agents) are what's gated, by **verification** (entry) and **reputation** (ongoing standing) alike. Makers chase trust rather than resent it. - **The unvalidated keystone is demand, not technology.** The components all exist; the combination is novel but unproven. Everything is gated on §8: whether enough audience-having, vouch-willing makers exist in one tight community.