# Miniatures Maker Platform — Strategy & Next Steps

A working memo distilling the thinking so far. The aim is to keep both 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.

---

## 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 itself), 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 cannot shortcut its accumulation.

The diagnostic question 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 that question is the real moat. If nothing survives, build-cost was the whole moat — and that's 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. Plan accordingly: don't pick a fight where build-cost was going to be your only moat.

---

## 2. The thesis

Build for **miniatures 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 unifying insight is that the entire "gnarly 20%" across these maker verticals is one mechanism wearing many costumes. Pre-order, raffle, drop, monthly club, made-to-order commission, deposit-and-waitlist — every one of them is *collect committed demand before production, then make against it.* That is the inverse of Shopify's model (*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 product category you're building is **commitment commerce**, not storefront commerce. Naming that defines the platform: the drop/pre-order/club/commission cadence is the engine, and the storefront is just its surface.

Two halves, deliberately 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, variant and bundle handling. This *is* the gnarly 20% and the reason vertical infrastructure here is defensible — it is emphatically *not* "the same as Shopify." (The white-label storefront is subsumed here as the commodity surface: build the least of it you can, rent the rest.)
- **Cross-maker demand network (the moat).** The flow asset, and it accumulates as a *byproduct* of the engine. Every drop/pre-order is an occasion to capture 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. Curated cross-maker inclusion (makers featuring each other, reputation-staked) is how that network turns into earned demand rather than relocated demand.

The key reframe vs. earlier drafts: commitment commerce is not a feature of the storefront — it *is* the platform, and it's the mechanism that builds the flow moat instead of something engineered separately alongside it.

**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.

**Why miniatures is a good vertical:** it expresses every form of the commit-then-make primitive at once — recurring monthly STL/digital releases (the Patreon / Tribes / Cults3D model), digital file 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 precisely where Shopify is mediocre and where commitment-commerce infrastructure earns its keep.

---

## 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 newer Product Network all let merchants sell each other's products. Feasibility is fully de-risked, but it also means **you cannot win on the plumbing.** If the product is "Collective for makers," Shopify extends Collective and you're gone.

Your differentiation must be the layer the commission-optimized networks structurally can't have:

- **Verified provenance.** Authenticity verification — "actually handmade/sculpted by this person" — is the trust signal buyers and AI agents can't get elsewhere. It *appreciates* as AI-generated and drop-shipped fakes proliferate (Etsy is being flooded right now). This is the flow asset; the aggregation tech is stock.
- **Reputation-staked curation, not pay-for-placement.** The central danger: margin/commission-driven inclusion drifts curation from "what's genuinely good" to "what converts and pays" — which rebuilds Etsy's pollution *from inside*, laundered through trusted faces. Inclusion has to be an editorial/social act with the curating maker's standing on the line, not a high-margin SKU import.
- **Community standing.** The demand problem is fundamentally 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 that AI shopping agents need and cannot 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, My Community Made, Storenvy, Amazon Handmade — "Etsy but actually handmade" has been built many times and every version stays small. The reason: **curation fights liquidity**, and curation is a *seller-side* value proposition, not a buyer-side one. These platforms recruit angry makers (supply) and die for lack of buyers (demand). Etsy's 2013 drift into mass-produced goods wasn't a betrayal — it was the gravity of GMV growth.
- **No demand advantage yet.** This is the binding constraint. Demand at a new marketplace's scale must be *earned*, not bought — paid acquisition against Etsy, Amazon, and agents is the losing game the whole graveyard played.
- **Early-stage, the network pools existing maker audiences (reshuffle), it doesn't create net-new buyers.** That's 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, your network's conversion advantage is capped. Surface this early.
- **n = 2 is learning, not validation.** The trap for an engineer 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 means inheriting structural delivery risk — chargebacks, non-delivery, makers who collect pre-orders and don't ship. This is *why* the 20% is gnarly (it's financial risk, not just UX), and it echoes Shopify's payments-loss exposure. Decide early whether you sit in the money flow and carry that risk, or stay payment-adjacent and let the maker carry it (all-or-nothing gates, delayed payouts, and maker vetting are the standard mitigations).
- **Raffle/lottery legality.** The raffle drop mechanic can be regulated as a lottery or gambling depending on jurisdiction — the one primitive in the set 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 (a maker funding one big run a year) is owned by entrenched incumbents (Kickstarter, Gamefound, BackerKit — see Appendix B). The unserved gap is the *continuous* maker drop cadence (the biweekly drop, the monthly club). Don't drift into competing with Gamefound; own the continuous-relationship layer they don't serve and let big campaigns happen elsewhere.
- **Volunteer-core sustainability is the new single point of failure** (given the non-profit/volunteer model — see §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 (drops, pre-orders, clubs, made-to-order) with a white-label storefront as its surface — genuinely the best home for a real miniatures maker. Useful at zero liquidity. Accrues supply, structured provenance-stamped catalog, *and* a base of drop-followers. *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. 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.
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 two makers)

Good investment **if** you build the right common infra. The wasted version is a generic storefront engine ("the same as Shopify") — that's 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 file delivery + licensing, and variant/bundle handling. This is the portable, vertical-spanning core; the storefront is just its surface.
3. **Standing in the miniatures scene** and two reference relationships.

**Operating rule: build the miniatures-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: money-flow stance & the first network feature

These are two decisions that turn out to be the same decision viewed twice.

### Money flow: stay out of it (the "no")

The white-label model already enforces this: because each storefront is the maker's brand on the maker's own payment processor, **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 (it processes pledges, takes a cut, pays out) and only disclaims *delivery* liability; here you avoid both the flow and the delivery liability structurally.

**Pros of staying out of the flow:**

- No money-transmitter / escrow licensing burden (holding customer funds triggers state-by-state MTL in the US).
- No chargeback exposure — chargebacks hit the merchant of record (the maker's processor), not you.
- No delivery-risk balance-sheet exposure — the Shopify "loan-and-transaction-losses up 84%" risk simply isn't yours.
- Clean SaaS margins; faster launch (no payments/underwriting/compliance build).
- Maker-aligned: their brand, their processor, their payouts, their customer, their data.

**Cons (real — the reason to phase rather than refuse forever):**

- You forgo payment take-rate, which the Shopify analysis showed is the actual profit engine. Pure-SaaS is a smaller model. (But the take-rate you give up is exactly the slice that carries the risk you're declining — a fair, deliberate trade.)
- The cross-maker identity moat can't come *from* the payment layer, because you don't own checkout.

**The reconciliation — you surrender neither economics nor the moat:**

- **Stripe Connect threads the revenue needle.** With connected accounts, the *maker* stays merchant of record (their bank, brand, chargeback + delivery liability), Stripe is the money transmitter, and you take an `application_fee` per transaction *without holding funds or the MTL burden* — plus transaction-level visibility. The middle path between pure-SaaS and full merchant-of-record. *(Verify the exact liability split across standard/express/custom account types with Stripe's docs and a payments attorney before architecting — platform liability genuinely varies by type. Not legal advice.)*
- **The identity moat lives at the *follow*, not at checkout.** The asset is "who follows which makers and commits early to drops" — captured at the account / "notify me" / club-membership layer you own *regardless* of whose processor runs the charge. It never needed the money flow.

**Phasing:**

1. **Phase 1 — white-label + their processor.** No liability, no network yet. Pure tool / consultancy.
2. **Phase 2 — shared identity/follow layer** threaded through all the white-label sites so the network can form. Optionally add Connect `application_fee` for transaction economics. Still no money-flow liability.
3. **Phase 3 (much later, optional, opt-in) — a shared checkout** makers *choose* because it converts better (the Shopify Payments move). The only point the money-flow question returns — on your terms, 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 cross-maker demand network expressed as a concrete, shippable product surface — and it works at **n = 2**, the holy grail for a network feature (almost nothing is useful at two nodes).

**What this is — and the name matters.** This is a **verified merchant referral network**, *not* retail media. The two are mechanically similar (a curated set of products with outbound links and attribution) but encode *opposite governance*: retail media is **paid placement** (the advertiser who pays most wins the slot; relevance is for sale), while a verified merchant referral network is **reputation-staked vouching** (placement is earned by being worth featuring; the curating maker's standing is on the line). Same shape, inverted soul. 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, which rebuilds Etsy's pollution through trusted faces.

**Targets are verified makers on controllable storefronts ONLY — never walled-garden listings.** The network never points its curation (or its buyer feed, or its agent feed) *outward* at an Etsy/Amazon/eBay listing. This is a **value-system rule, not a technical limitation**: every outbound link into a walled garden would lend the community's trust and a maker's audience to the exact captive-commerce model this enterprise is an alternative to — sending makers' buyers *into* the gardens you exist to get makers *out* of. Mechanically possible, philosophically self-defeating. Consequence: 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 toward sovereignty. (This also strictly sharpens the moat: when every target must be a verified, controllable-storefront member, the "sincere vouch vs. paid slot" gray zone disappears entirely.) See Appendix D for the full participation matrix.

**The fork that determines everything — what "buy" means:**

- **(A) Referral / handoff — build this.** Checkout hands off to maker B's own store and processor. A vouches, B fulfills and gets paid, A optionally earns a referral credit. Money stays cleanly siloed; A is never merchant of record for B's goods. Keeps you out of the money flow — *consistent with the "no" above.*
- **(B) Consignment / resale — avoid (for now).** The buyer checks out on A's store, through A's processor, for B's product. A becomes merchant of record for B's goods and owes B a payout — recreating the delivery-and-payout liability you just designed out. This is mechanically what Shopify Collective is, and why it needs Shopify Payments in the middle. Re-opens the money flow.

**Why A is the elegant choice:** it's reputation-staked human curation (A puts their standing behind B) — the anti-pollution, can't-be-gamed curation that *is* the moat; it rides each maker's existing traffic (the mesh that pools demand without you buying it); and it's structurally aligned (A only features B if A rates B's work).

**How the two halves connect:** A (handoff) *is* the money-flow "no" applied to the network feature. The referral attribution that makes A work is powered by the **Phase-2 shared identity layer** — a buyer recognized across A's and B's white-label sites is what makes "A drove this sale to B" tractable without anyone being merchant of record for anyone else. A referral *credit* can be a platform-side ledger entry, not a money-movement event — keeping you out of the flow even while rewarding curation. The feature, the identity layer, and the money-flow stance are one coherent bet.

**Guardrails (A degrades into the failure modes if done carelessly):**

- **Attribution is stateless — it does *not* require the identity layer.** A signed referral token (origin maker + item + expiry + nonce) rides the A→B handoff into B's order; you read it at checkout to bill B and credit A. This tracks the *referral path*, not the buyer, so it works in Phase 1 for guests and fully sovereign makers alike. Persistent identity is only needed for the *durable* network effects (follows, cross-session credit, recognition lift) — see the identity subsection below.
- **Commission-corruption trap.** The moment "Curated By" pays well, curation drifts from *vouch for work I admire* to *feature whoever converts/pays most* — Etsy's pollution rebuilt through trusted faces. Keep it reputation-staked: cap how much any maker can feature, make it visibly personal (name + face on it), prefer "A owns/uses this," and resist turning slots into paid placement no matter how tempting. The sincere vouch is the whole value.
- **Competitive-adjacency rule.** Nudge toward *complementary* makers, not substitutes (the dice maker surfaces the dice-bag sewist or terrain sculptor, not a rival caster). Complementary curation is generative; substitute curation is cannibalistic, and makers won't do it.

**The phrase to interrogate in your own spec: "buy through their store."** It's the soft spot where (B) creeps back in — someone will ask for unified-cart "so buyers check out once across makers," and that convenience is exactly what drags you back to merchant-of-record and the money flow. Hold the line at handoff until a shared *opt-in* checkout is a deliberate Phase-3 decision.

### How the platform gets paid

Because you're out of the money flow (maker is merchant of record on their own processor), your fee is a **platform fee billed in arrears via the ACH/invoice model**, explicitly separate from processing — you can't skim a sale you don't touch. The comparable that matches this architecture is Checkout Page ($29/mo, 0% on top of the maker's own Stripe). The structure:

- **Tiered "graduate" pricing.** Starter tier: $0 or low monthly + a modest **percentage** (≈2–4%) on captured orders — adoption-friendly for cold start. Pro tier: flat **$29–49/mo + 0%** — predictable and easy to collect, for makers at scale. Auto-graduate by GMV threshold so makers aren't accidentally overpaying. (Industry norm: start transaction-fee-only to validate, switch to subscription around $3–5k/mo.)
- **Use a percentage, not a per-order flat fee**, on low-AOV makers (dice, single minis) — a flat $0.50 disproportionately taxes a $12 item.
- **Charge on captured/fulfilled orders, not pledges** — pre-orders get cancelled/refunded; don't bill on 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 (Curated-By).** On a referred order, charge Maker B a **referral fee** (≈15%, marketplace convention à la Faire/Amazon Handmade) and *independently* credit Maker A. Keep these as **two separate events** — B→Platform (a fee on B's invoice) and Platform→A (a credit you extend) — so you act as **principal on both sides, never as a conduit** moving money B→A. That two-step independence is what keeps this out of money-transmission territory, and it holds *only* while A's credit is non-cashable.

- **The referral fee subsumes the standard fee on referred orders** (one clean "15% because referred" number), rather than stacking 15% on top of your normal cut and drifting 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, not just fee-offset.
- **Non-cashable fee-offset wallet.** A's credit accrues to a wallet that draws down *future platform fees first*. This drives the curation flywheel ("curate → wipe out your fees"), reduces your collection risk (referral-active makers self-offset their invoices), and — being a fee discount, not income — is cleaner on tax (no 1099 event). **Cashing out re-opens the money-flow/transmission door** and would require renting BaaS money-movement infra (Stripe Treasury/Connect/Dwolla); treat it as a deliberate later crossing, not a toggle.
- **Settlement on a pending → cleared lifecycle.** Credit A as *pending* immediately (engagement signal) but not spendable; hold B's fee pending too; settle **both legs together** after B's refund window closes. In-window refunds void both atomically — zero clawback, nothing goes negative. Clear on the *refund/return* window (≈14–30 days), not the ~120-day chargeback window. Rare post-clearance reversals fall to the next mechanism.
- **Negative balances are just a debit on a continuing account.** Reverse pending first, then available, then push any shortfall to the maker's next ACH invoice; floor the displayed wallet at zero and show "owed next invoice." The monthly billing cadence *is* the settlement job — include only window-closed referral events per invoice. Only real bad-debt case: a maker simultaneously churning, having spent cleared credit, then eating a late reversal — keep the ACH mandate active through offboarding; accept minor write-off; consider 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 their store (run by 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 (recognition, referral, Curated-By).
- **Centralize auth always** — it's commodity infrastructure *and* the foundation of the network. If auth fragments per store, even opted-in makers have no shared substrate to network across, destroying the keystone identity asset. The maker's choice is a flag on one system, flippable later without re-platforming (which is what makes the opt-in upgrade path work).
- **Two consent layers:** the *maker* decides whether their store participates; the *buyer* decides whether they're recognized across the network (GDPR/CCPA). Build both flags from the start — far cheaper than retrofitting.

**Opt-in network model.** Joining the collective is opt-in — carrot, not stick, and it self-selects the commons-minded makers the network works for. Critical execution rule: the benefit must be **concentrated and visibly fast**, or opt-in collapses into a ghost town. Make the asymmetry **additive** (joiners get referral income, Curated-By placement, cross-promotion, fee offset, feed surfacing) — never **punitive** (do not cripple the standalone storefront to force joining; that breaks the Phase-1 promise and poisons trust). Design for: **granular** participation (e.g., outbound curation without inbound identity-sharing), **reciprocity** (surfacing proportional to participation, so no free-riding), and a **social-proof opt-in moment** ("makers you respect sent each other 200 buyers last month — want in?").

**"On our storefront ⇒ on the network" — split this into two switches; don't bundle.** Being a storefront maker should *not* force full network participation — that's the coercion the opt-in model rules out, it reintroduces the sovereignty problem for the maker who wants your drops-storefront without sharing buyers, and it weakens the storefront's standalone (n=1) value. The clean version separates two switches:

- **Catalog presence in the network** (your products *can* be discovered/curated/fed): reasonable to **default-on (opt-out)** for storefront makers — they're verified-eligible and their catalog is already in your system, so syncing it into the index is low-friction, high-value, low-sensitivity.
- **Buyer-identity participation** (your *buyers* are recognized cross-maker): must stay a **separate, consent-gated opt-in** — it's the sovereignty-sensitive part *and* it's the buyer's data, not just the maker's.

So storefront onboarding can default *catalog* into the network as a fair convenience, while *buyer-identity sharing* remains an explicit, separate choice. Bundling the two would trade a hard-won neutrality/trust position (what wins fortress-leaning makers and differentiates you from Etsy/Shop-app) for a small onboarding convenience — a bad trade. Take the convenience (auto-catalog-sync); never the coercion (forced identity participation).

**Why this is the defensible core.** Shopify *won't* build cross-merchant shared identity — not because it's technically hard, but because its customers (sovereignty-seeking DTC merchants) would experience it as the platform claiming their buyers, betraying the exact promise Shopify sells. It does the *resell* network (Collective/Carro/Product 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 — so you can serve the buyer-relationship norm Shopify's base would revolt against. 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.

### Verification: the gate to the trust tier

Verification sits exactly at the boundary between the commodity layer and the moat layer. Everything below the line is the SaaS tool (anyone); everything above requires verification (the trust-gated network). There are three states, not two.

**Tiering:**

- **Unverified → full SaaS, zero network.** Any maker signs up and gets the complete commitment-commerce storefront (drops, pre-orders, clubs, their own processor). They're a paying customer of a genuinely good tool. They are simply not in *anything* trust-gated: no referrals (send or receive), no Curated-By (as curator *or* target), no buyer-feed surfacing, no agent feed. Rationale: the storefront is the commodity layer; gating it would suppress the Phase-1 adoption wedge. Let everyone in the front door.
- **Verified → eligible for the trust tier.** Verification unlocks *eligibility* for referrals, Curated-By, buyer feed, and agent feed — not automatic inclusion.
- **One gate, then independent switches.** Verification is the single floor to the entire trust tier; 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 reputation-stake can't vouch for unverified supply, so Curated-By can feature *only* verified makers, and an unverified maker can't be the *target* of a referral either. Fully outside the graph both ways until verified. (Useful forcing function: wanting to be curated by your friends is a reason to verify.)

**Network opt-in and agent (ACP) opt-in are independent siblings over one shared verified catalog — do not gate agent inclusion behind network membership.**

- **Network opt-in** (maker-to-maker): identity sharing, Curated-By, referrals, buyer feed.
- **Agent/ACP opt-in** (maker-to-machine): verified catalog exposed to external AI shopping agents.
- A sovereign, fortress-minded maker may refuse the maker-to-maker network but *want* agent reach — because agents bring **net-new, sovereignty-neutral demand** from outside any maker's audience. Gating agents behind network membership would exile exactly the makers who most want agents.
- **Verification — not network membership — is the precondition for the agent feed.** Agents need trustworthy, structured, verified-provenance supply (what OpenAI's Instant Checkout died for lack of). The agent feed thus inherits the core differentiator automatically: "*verified-handmade* products for agents."
- **Default agent inclusion ON (opt-out) for verified makers.** Net-new sovereignty-neutral demand that most will want; default-on maximizes supply density, which is your leverage with the agents. Safe because agent sales route back through the maker as merchant of record (their processor, their fulfillment, your fee).
- **The agent feed is the net-new-demand hedge** against the buyer feed's deliberate reach-weakness: the buyer feed *deepens* existing follow graphs, the agent feed *reaches* outside them. Complementary by design — another reason to want the widest verified participation in the reach engine.

**Verification is aspirational, not punitive — by design.** Because it gates the *demand* (referrals, feed, agents) and not the *tool*, makers are pulled toward verifying rather than blocked at signup. The unverified SaaS tier becomes a **verification funnel**: makers already paying, already with catalog in-system, upgrade path = "verify → unlock demand." And it keeps the trust guarantee **absolute** — both consumer-facing surfaces (buyer feed and agent feed) are hard-gated, so anything a buyer or agent sees through the network is verified.

**Peer verification — the scaling mechanism for the gate.** Makers verify other makers, staking their reputation. This is the right way to scale because it's *provenance verifying provenance* (real makers spot real makers better than any central reviewer), the verification web *is* a trust graph (harder to replicate than a checkmark database — it deepens the moat, not just scales it), and vouching/being-vouched-for doubles as community formation. **But it's the highest-stakes mechanism in the design** — a Sybil/collusion attack surface that fails *catastrophically*, because one polluted item reaching the "verified" feed breaks the entire guarantee. Build it as a *rooted, staked, multi-vouch trust web with a sampling audit*, never a flat "anyone verified can verify anyone":

- **Real, slashable stake.** If A verifies C and C is a reseller, A suffers a concrete consequence (verification authority revoked, own status reviewed, privileges suspended). The stake must *hurt*, or "staked reputation" is just a farmable click.
- **Earned authority / time-trust gradient.** Newly-verified makers can't immediately verify others; authority accrues with tenure, clean record, and volume. This breaks ring-bootstrapping (you can't spin up accounts that instantly cross-verify).
- **Rooted graph.** Anchor early verifications to a seed set *you* verified directly (community pillars); peer verification extends outward from trusted roots, so every verified maker traces back through a path to a root — and a compromised subtree can be found and revoked. A flat graph has no roots and no way to contain a breach.
- **Multiple independent vouches** for full status (N verified makers, ideally not all from one cluster — independence matters more than count).
- **Sampling audit on top**, sized to risk: random plus risk-triggered (new clusters, rapid cross-verification, mass-produced-*looking* products, buyer/agent complaints). You don't review everyone; you make abuse expensive and detectable.
- **Instrument for ring patterns from day one** — cross-verification clusters, reciprocal-vouch loops, bursts, makers who only verify each other are detectable graph signatures.

**Sequencing: do *not* launch with peer verification.** Verify makers yourself early — you'll have few enough that manual review is feasible, and you *need* to personally establish the root set the web later anchors to. Turn on peer verification only once trusted roots exist and volume makes manual review the bottleneck. Seed manually first; enable deliberately. Note that verification is now load-bearing in four places (referrals, Curated-By, buyer feed, agent feed), so verification throughput is a real growth governor — worth designing the scaling path (tiered verification, community vouching as signal, provenance-documentation standards) early.

### Non-maker referrers: the verified taste-maker tier (Phase 2)

Any website can join as a *referrer* — a taste-maker/curator (painting YouTuber, tabletop blogger, hobby podcaster) who isn't a maker but has audience and taste. It's financially low-risk (pay-on-conversion, no custody, no MoR, no inventory — mature affiliate plumbing you already have). The risk is to the **verification moat**, and it's handled by the *same verification tiering as makers*:

- **Unverified referrer (open tier).** Anyone generates referral links to verified makers and earns on conversion, but is **not surfaced in any trust-dependent surface** (no trusted-curator badge, no buyer-feed placement, no appearance in others' Curated-By). Just a traffic source pointing at your makers — self-limiting (a bad referrer doesn't convert) and contained (can't touch trust surfaces, so can't pollute them).
- **Verified taste-maker (trust tier).** A legitimate community voice, verified as a *trusted curator* (not as a maker), reputation-staked and slashable — gets the badge/surfacing/"vouched taste" treatment and loses it for shilling garbage. The same reputation-stake principle that makes maker curation pollution-resistant. Verification is what separates the genuine taste-maker (additive) from the affiliate-spam farm (corrosive).

**The load-bearing guardrail: uniform, non-biddable referral rates.** A maker-curator has a dual incentive (fee + peer respect + their own maker reputation) that counterbalances commission pull; a pure taste-maker's incentive is more purely the fee. If makers could set *different* rates, taste-makers would chase the highest payer — bidding-for-placement, i.e., retail media through the referrer door. So the rate is **uniform across makers (not biddable for placement)**: the taste-maker earns the same regardless of *which* verified maker they feature, so they feature on **taste, not who pays most.** This is what keeps the verified merchant referral network from sliding into retail media even with pure-commission referrers in the system.

Smaller rules: **disclosure/labeling** — distinguish a maker's reputation-staked peer vouch ("Maker A uses & vouches for this") from a taste-maker's disclosed-affiliate pick ("Curator X recommends this — earns a referral"); FTC-required anyway, and it protects a maker's vouch from dilution. **Referrer-only, one-directional** — a taste-maker is never a *destination* (nothing to sell) and never a *maker-verifier* (provenance verification stays maker-to-maker); they point traffic *at* verified makers, full stop. **No-walled-garden rule still holds** — they refer *to* verified makers on controllable storefronts, *from* their own controllable property; nothing routed into a garden.

**Why it's worth doing, not just safe:** taste-makers are the **net-new-demand engine** the maker-only network is structurally weak at. The buyer feed only deepens existing follow graphs; the agent feed was the lone net-new hedge. A respected hobby creator brings *genuinely new buyers* (who follow no maker yet) — a third demand source alongside maker-curation (deepens) and agents (reach), and the most community-native of the three (a trusted human voice, not an algorithm).

**Why Phase 2 — and why it's a marginal add, not a new crossing.** A pure referrer has no platform fees to offset, so the non-cashable wallet (what kept Phase 1 out of money movement) is *trapped value* for them — they need **cashable payout**, exactly the rail Phase 1 deliberately omits. But it's the *same* cashable Connect/mass-pay rail Phase 2 already needs for **cashable maker wallets** and **kit pure-supplier payouts** (Appendix C) — so taste-makers are a *third consumer* of one rail, not a new crossing. The marginal cost is the verification tier + uniform-rate guardrail, not new money plumbing. (The crossing's nature: paying a taste-maker is a *payout* to an affiliate/contractor — principal-on-both-sides, maker→platform fee and platform→taste-maker commission as two independent events — not consumer money transmission; rentable via Connect / PayPal mass-pay / Dwolla.) **Reserve option:** a marquee taste-maker who wants in before the rail exists can refer and *accrue a pending cashable balance in Phase 1, paid on rail launch* — captures the relationship early without building the rail early; reserve for a marquee curator (you're booking obligations you can't yet settle), don't open generally.

### Phasing the network (stateless → identity → feed)

1. **Phase 1 — stateless referrals.** Curated-By with signed tokens only. No auth dependency, no consent complexity; works for guests and sovereign makers. Ships early; buys *attribution*, not *recognition*. Maker-to-maker only, non-cashable wallet — fully out of money movement.
2. **Phase 2 — persistent identity + the cashable-payout rail.** Shared auth + follow relationships + the cross-maker graph (consent-gated): the durable network effects (follows, cross-session credit, niche-scoped recognition/conversion lift). Phase 2 also lands the **cashable payout rail** (Connect/mass-pay), which is a single build that simultaneously unlocks **cashable maker wallets**, **kit pure-supplier payouts** (Appendix C), and the **verified taste-maker tier** (above) — three consumers of one scoped, rented crossing.
3. **Phase 2+ — buyer-facing feed.** A consumer surface (site/app, plus 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 being launched cold into the curation-vs-liquidity graveyard (§5's "earn into the marketplace").

   **Core principle — discovery is delegated to makers the buyer chose, never performed by the platform.** Every recommendation traces to a follow the buyer initiated: their followed makers' drops, buy-it-again from those makers, and Curated-By *from those same makers*. 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.** This is the *inverse* of the Shop app (platform-as-discovery-engine with algorithmic feeds and sponsored placement), and it's the line that keeps the feed from sliding into the model this whole strategy avoids. 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 is shown a maker they didn't choose to follow or that a followed maker didn't vouch for); and it preserves **curation integrity** (human, follow-gated, reputation-staked curation can't be gamed toward pollution the way an engagement algorithm can).

   **The deliberate tradeoff to name:** pure follow-gated discovery is intentionally *weaker at net-new demand* — it deepens and cross-pollinates the graph buyers already know, but does not introduce buyers to makers outside their follow/curation graph. The growth engine stays permanently "makers bring audiences and vouch for each other," never "the platform surfaces new reach." That's the correct trade for this positioning (it's what protects sovereignty and trust), but it puts the entire demand burden on makers and their curation by design — a feature for this model, not a bug, as long as it's chosen knowingly.

   Additional disciplines: **buyer-opt-in by nature** (which doubles as cross-merchant data consent); lead with the safe end (buy-it-again → followed drops → curated-by); respect maker-side policy on appearing in others' recommendations. Any future move toward platform-originated/algorithmic discovery is a deliberate, opt-in-by-everyone, much-later decision — not a default.

### Storefront architecture & Shopify coexistence

**Two layers, kept separate — this is the core architectural decision.** The system is a *storefront layer* (per maker) sitting under a *shared cross-maker network service* (the moat). Conflating them couples the moat to one storefront engine and to single-tenant boundaries; keep them apart.

- **Storefront layer (per maker).** Either your **white-label storefront** (headless backend + themed frontend) or the maker's **existing Shopify store** (federated — below). Handles that maker's catalog, cart, checkout, orders, and their own payment processor (merchant of record).
- **Shared network service (cross-tenant — the moat).** Verification graph, **canonical catalog index**, cross-maker identity/follow graph, referral/Curated-By attribution + fee/wallet ledger, buyer-facing feed, agent/ACP feed. A standalone service with its own datastore. It spans *all* makers and federates over *heterogeneous* storefronts (Medusa and Shopify alike), so it is deliberately **not** part of any storefront engine.

**The canonical catalog index lives in the network service — not in a Medusa "mega-store."** Every network maker's catalog (Shopify via Admin API, your own Medusa storefronts via their API, anything else via adapters) is *transformed into one normalized, verified catalog index* that powers Curated-By, the buyer feed, and the agent feed. Do **not** pour all makers' products into a single Medusa instance: a Medusa instance is a *storefront* (cart, checkout, pricing, one merchant-of-record, sellable inventory), but the network catalog is a read-optimized *index* of products that live and sell elsewhere — it has no checkout and no single MoR, and its inventory is authoritative on each maker's own storefront. Routing it through Medusa would make a thing shaped like a store that must never behave like one, and would quietly couple the neutral network to one storefront engine. Keep each storefront (Medusa or Shopify) as the system of record for sellable catalog/inventory; the network holds a normalized verified *projection*. Landing the index in your own schema (not Medusa) is also what keeps Shopify and Medusa products *co-equal sources* feeding one neutral index, rather than Shopify products being second-class imports into a competitor-shaped container.

**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 (Python/GraphQL), Vendure (NestJS/TS), Spree (Ruby, natively multi-tenant white-label)) supplies cart, catalog, orders, customers, fulfillment, and BYO payment. You add the commitment-commerce engine — **drops, pre-orders/deposits, clubs/memberships, raffle/queue — as custom backend modules + workflows.**

- **Mental model (important):** in Medusa, *modules are backend domain logic; the storefront is a separate frontend app* (Next.js/Astro) consuming the Store API; the admin is separately extensible. 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 (it's standalone).
- **Multi-tenancy:** one shared Medusa instance with app-layer tenant isolation (simpler, fine for early scale) *or* per-maker instances (stronger isolation, the "self-host per-instance" model). The network service is separate either way, so this choice is decoupled from the moat and can be deferred. For the two pilots: single instance + shared theme + minimal per-maker config; don't over-build theming for n=2.

**Shopify makers: federate, don't migrate.** Because the network layer is storefront-agnostic, a Shopify maker keeps Shopify as storefront + checkout (their MoR/processor) and joins the network via two hooks:

- **Catalog sync (inbound):** pull their catalog via Shopify Admin API + product webhooks into the verified-supply graph; once verified, their products are eligible for Curated-By, buyer feed, and agent feed — without leaving Shopify.
- **Referral handoff + attribution:** the Curated-By link hands off to their Shopify product page with a signed referral token, which rides in as a **cart attribute → order note_attribute**, read back from the order webhook to bill B / credit A. Needs no checkout customization, so it works on *any* Shopify plan.
- **Hybrid wedge:** evergreen catalog stays on Shopify; the maker uses your platform only for the commitment-commerce *events* (drops/pre-orders/clubs) Shopify handles badly. Lowest-friction entry; migrate the evergreen catalog later only if earned.

**Curated-By on Shopify — the concrete integration.** A Shopify maker plays two roles, both delivered through **one installed app** built on **theme app extensions** (not legacy ScriptTag — required for OS 2.0 themes and App Store submission; keep ScriptTag only as a fallback for vintage themes):

- **Curator role → an app *block*.** A draggable "Curated By This Maker" block the maker drops onto a product/home page in the theme editor (no code; auto-removed on uninstall). It fetches the maker's *verified* curated picks from your network service (the source of truth) and renders cards that hand off to the target maker's store with the signed referral token. Works on product/collection/cart/home/blog pages on any plan — only checkout is off-limits without Plus, which you don't need.
- **Recipient role → an app *embed*.** A script (toggled in the theme editor's "App embeds" panel) reads the inbound `?ref=` token on landing, persists it, and writes it as a **cart attribute** on add-to-cart. Cart attributes flow natively into the order as **note_attributes** through standard checkout; you read them from the `orders/create` webhook to bill B / credit A. No checkout customization, any plan.
- **One app = joining.** A maker who both curates and receives installs the single app (block + embed); installing it *is* how a Shopify maker joins Curated-By. The app is a thin client — curation choices, verification, and the referral ledger all live in your network service; the maker manages picks in your dashboard or an embedded App Bridge admin.
- **Optional:** an **app proxy** (`makerstore.com/apps/curated` → your backend) for server-rendered, crawlable curated sections under the maker's own domain. **Attribution discipline:** persist the ref on landing and re-attach on every add-to-cart; last-click single-hop, matching the stateless model.

The headline: because it rides cart attributes through native checkout, the *entire* Curated-By loop — display and attribution — works on a completely standard 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 as network participants 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 API integration is partly rented land (rate limits, API changes, possible competition), but you're not dependent on it (one source among several); Shopify takes its cut on Shopify-store sales (fine — you meter the order webhook and bill your fee separately via ACH).

**Admin surfaces — three, not two.** The admin layer falls along the same seam as the architecture: the *network* is one product with one admin for *everyone*; the *storefront* is a separate product whose admin is Medusa's (your makers) or Shopify's (theirs).

- **Storefront admin — only for makers on your platform (Medusa).** Products, drops, pre-orders, clubs, orders, fulfillment, inventory for their own store. Use/extend Medusa's admin for the commitment-commerce modules. A Shopify maker gets *none* of this from you — Shopify is their storefront, so they manage all of it in Shopify's admin.
- **Network admin — universal (every participating maker, Medusa or Shopify).** Curation/Curated-By management, referral earnings + fee-offset wallet, verification status + peer-vouching, follow/feed participation, network opt-in toggles, agent/ACP inclusion. **Bespoke build** — it has no home in either Medusa's or Shopify's admin because it's the cross-tenant moat layer above both.
- **Billing/account — universal.** ACH mandate, fee tier, invoices, payment history. Bespoke, tied to the network service.

Mental model: **everyone uses your bespoke network + billing admin; Medusa makers *additionally* get Medusa's storefront admin; Shopify makers get their storefront admin from Shopify.**

- **ACH is universal, not referral-specific.** Every maker gives an ACH debit mandate at onboarding — it's how the platform collects all fees (subscription, per-order/%, *and* referral). Shopify makers (who have no account on your storefront) attach it through the network admin or the app's embedded setup, via GoCardless / Stripe-Billing-ACH. **Make mandate-on-file a precondition for activating referral eligibility** (gate it where you gate verification) — otherwise a referral-only maker accrues a fee you can't collect, and you avoid the negative-balance edge case for makers with no other invoice to net against.
- **Shopify makers get a read-mostly catalog/sync/analytics view — a trust surface, not a convenience.** (1) **Synced catalog as a mirror, not a second editor** — Shopify stays system of record; your view shows the ingested catalog annotated with network metadata (verified? in agent feed? curated by whom?). Two editing surfaces = sync-conflict nightmare; keep it read-mostly. (2) **Sync health** — last sync, what came through, what failed, webhook status; when a sync silently breaks, a maker whose products vanish from the feed loses faith fast, so surface this prominently. (3) **Network analytics** — referral traffic/revenue (in/out), Curated-By performance, feed/agent-attributed sales, wallet/earnings. This is *uniquely yours to provide* because only you see across stores, and it does quiet retention work: the maker who can see "Curated-By sent me $800 last month" stays and participates more.

**Build-ordering implication:** the bespoke network + billing + analytics admin is **foundational and on the critical path for both maker populations from day one** — even the two Medusa pilots need it the moment Curated-By and referrals exist. Medusa's admin extension is the storefront-specific layer on top, not the other way around.

### Business model: network is the product, storefront is an optional convenience

Now that Medusa exists and the network federates over any storefront, the case for *centering* on storefront hosting has weakened — three independent erosions: the storefront is the commodity layer; Medusa makes that layer cheap for everyone; and federation means a maker doesn't *need* your storefront to be in the network. The resolution is a deliberate posture about role and pricing:

- **The network is the product and the value capture.** Charge for the network — referral take + network subscription — **uniformly, whether a maker is on your storefront or on Shopify.** Revenue must not depend on storefront adoption; that's what keeps you credibly neutral and feeds the moat (TAM = *every* maker, not just storefront adopters).
- **The storefront is an optional, opt-in convenience — SaaS-priced, never GMV.** Drop the GMV storefront fee: 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 the money-flow/MoR entanglements you escaped. Price the storefront as a flat SaaS fee that covers its cost; capture value in the network. A maker's storefront choice then doesn't change what they pay for the network.
- **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, where the storefront is the best-in-class native commitment-commerce experience for makers who want it or have nowhere else to be (the two pilots; greenfield makers), and a wedge — not the business.

**"Why not just point makers to Medusa Cloud?"** Because Medusa Cloud sells *hosted infrastructure to developers*; it does not give a maker a working drops-and-clubs storefront, and never will. You sell a **vertical, maker-ready commitment-commerce product** (drops, pre-orders, clubs, made-to-order, verified provenance, turnkey setup) 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 discipline: **don't position or price as a hosting company.** Framing yourself as "Medusa Cloud + modules" drags you into competing on hosting/infra margins. Hosting is a cost you absorb; the vertical experience (and the network) is what you sell.

**Partner / consultant network.** A channel of implementation consultants (community-embedded ones especially) onboards the **high-touch tail** — makers who want bespoke theming, migration, or "someone do it for me" — without you becoming a services business. It doubles as community-aligned distribution (trusted insiders bring makers) and mirrors the partner ecosystems that grew Shopify and Medusa. It's a second flywheel you *enable* (certification, partner referral fees, a directory) but don't *staff*. Two guardrails: keep the product **genuinely self-serve for the median maker** (partners serve those who *want* help; if makers *need* a consultant for a basic store, the product has failed and partners are masking it); and structure partners as **referral/implementation partners, not white-label resellers**, so consultants don't become the relationship-owner and disintermediate you from the maker (the buyer-ownership tension, one level up).

### 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 is not a hedge or a branding choice — it's the structure that converts the trust position from a *promise* into a *guarantee*, and it's funded-viable for a reason that is thematically exact rather than incidental.

- **The cost structure that usually makes non-profit tech infeasible is the exact one LLMs just collapsed.** The primary cost center — engineering — has been deflated by the same force the venture exists to exploit. The entity structure and the market opportunity are *the same bet pointed in two directions*; the thesis (LLMs collapse build cost) applied to the org itself is what makes a volunteer-built non-profit viable.
- **No fundraising removes the only strong argument against true non-profit.** (An earlier draft considered a PBC/B-Corp hedge — its entire purpose was preserving the ability to raise VC and grant equity. With fundraising off the table, that optionality is optionality you *don't want*, because it's the door — take growth capital, get acquired, chase GMV — that makers fear. The non-profit forecloses it.)
- **The structure *enforces* the anti-Etsy promise rather than signaling it.** A 501(c)(3) legally cannot be sold or distribute profits to owners — the strongest possible structural answer to "will you get big, let resellers in, and sell our trust for GMV?" This is "bind with structure, not promises" realized in the entity itself: the extractive path is legally foreclosed, not merely disavowed.
- **Radical transparency is the substrate of the verification moat.** Trust is the whole moat, and open books / open governance / an auditable verification process let the community *verify the incorruptibility* of "verified handmade" rather than take it on faith. Transparency makes the verification trust-guarantee *legible* — it's the mechanism, not a nice-to-have. (It's also the Wiggleverse ethos — intentional, non-extractive, transparent — expressed as an institution.)

**The risk moved; it didn't vanish — apply the rigor you'd have spent on fundraising to volunteer sustainability.**

- **Volunteer engineering is now the single point of failure.** LLMs change the *math* (a smaller core does what five engineers used to) but not the *human dynamics* of volunteer commitment — attrition when day jobs spike, bus-factor risk, best-effort cadence. A network touching makers' money, catalog data, and verification needs *reliability*, not best-effort. **Separate what must have reliability guarantees (the network service, the money/ledger, verification) from what can tolerate volunteer cadence (themes, nice-to-haves), and ensure the critical core is not bus-factor-one.** LLMs accelerate *building*; the historical killer of volunteer orgs is *sustaining*.
- **Watch the "fragile" perception with professional makers.** Non-profit + volunteer + transparent reads as *trustworthy/aligned* to commons-minded makers, but possibly *fragile/might-fold* to professional, audience-having makers building a livelihood. Radical transparency (open books showing a sustainable operation) is the strongest counter — test in the §8 interviews whether it reads as **safe** (won't sell out) or **nervous** (might disappear).



### Hosting: managed vs. self-host (and the GCP pilot)

**What you sell and where you host are independent decisions** — makers never see the infrastructure, so hosting is a pure cost/ops optimization, and it's *reversible and invisible* because Medusa is open-source and portable. Start managed for speed, migrate to self-host when volume makes the economics worth the ops burden, without makers noticing.

- **Managed (e.g., Medusa Cloud) now; self-host at scale.** Early, your scarce resource is attention on product + network, not infra savings — managed avoids DevOps/upgrades/on-call. At scale, self-host wins on unit economics and avoids coupling margins to one vendor's pricing.
- **Multi-tenancy interacts with hosting price.** Per-maker instances multiply managed per-instance pricing by maker count; a shared multi-tenant instance is far fewer (larger) instances with very different math. Negotiate volume pricing knowing your instance *count*, and pitch as a *multi-instance platform customer* (a better rate card than a single-store merchant).
- **The network service is hosted separately, always.** The cross-tenant moat layer (verification, referral ledger, identity, feed) runs as its own service + database, untouched by any storefront-hosting choice. That separation is what makes the hosting decision 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 GKE cluster you don't need at n=2; the shared-instance cost for two makers is low tens of dollars/month. **Watch the drop-traffic spike** — a scheduled drop is a sudden burst of concurrent buyers, exactly the load that embarrasses an under-provisioned instance; a storefront falling over *during a drop* is the worst possible moment for maker trust, so load-check before a real drop. On cost recovery: pass-through or a flat hosting fee is fine, but **treat cost recovery as the trivial part** — the bill is small, while two happy, well-treated pilot makers (your first verification roots and reference relationships) are worth far more. Optimize the pilot for learning the commitment-commerce 20% and goodwill, not for reconciling a GCP invoice. And frame any hosting charge as "covering pilot costs," not as the product's pricing model — don't anchor on cost-plus-hosting, which you've already decided against.

---

## 8. Next step: maker discovery (do this before building the platform)

Goal: verify whether Shop Pay's conversion advantage is a *real moat for these specific makers*, and whether you can build your own version of it.

**Avoid the measurement trap.** Don't ask "how much value does Shop Pay give you" — makers can't see the conversion counterfactual (they see the sales they got, never the carts they'd have lost), so answers are pure vibes. Shop Pay's lift comes from **cross-merchant identity recognition removing first-purchase friction.** So measure the thing that drives it:

- What's your revenue split between **repeat fans vs. first-time strangers**?
- Do your buyers tend to **already have Shop Pay**?
- (Repeat-fan-heavy makers capture little of the network effect — those buyers convert anyway. 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 Shop Pay-equivalent, scoped to the niche. You can't offer it on 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 directly):**

- Where their buyers come from today — the traffic-mix tell.
- What they pay Shopify **all-in** vs. what they *think* they pay — most underestimate, and the gap is your opening.
- Whether the value-alignment grievance is real willingness-to-switch or just venting.
- Whether they'd want **shared buyer recognition** across a network, or guard their list.
- **Whether they have an audience they'd bring** — the asset they'll least volunteer. A maker with no audience joining the network is a cost, not an asset.

**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 are the ones who already maintain a second channel, already *moved* on something, already bring their own buyers. Find whether those exist in miniatures — and whether you are one of them.

---

## 9. Decision gates

Gate the real platform build on evidence, not enthusiasm:

- Do the first two makers **refer you** to others?
- Is the **pain consistent** across makers (same 20%)?
- Do target makers **have audiences**?
- Can you get to 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.

---

## Appendix A — Adjacent maker verticals: pros, cons & expansion strategy

Competitive scan of candidate verticals beyond miniatures. The recurring finding: in every vertical 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. Scored on the transferable filter — made-to-order/drop motion, non-fungible inventory, hybrid digital+physical, recurring drops, variant explosion, audience-having makers, authenticity grievance, scalper/counterfeit problem, reachable community hub.

| Vertical | Pros | Cons | Flow layer (curation/demand) | Adjacent to minis? | Expansion strategy / verdict |
|---|---|---|---|---|---|
| **Resin dice** | Drop culture is the *default* motion; large maker audiences (20K+ IG); vivid authenticity grievance (China cast-copies undercutting real casters); active scalper secondary market makes queue/anti-flip mechanics valuable; drop/queue/commission infra is genuinely **unserved**. | Lower price points than knives; casting is labor-intensive (maker-side throughput limits); some design-theft enforcement complexity. | **Open** — no vertical platform owns drops or maker-following. | **Yes — same tabletop buyer.** | **Top pick / first expansion.** Treat as expansion of one community, not a new vertical. Reuse minis' made-to-order, pre-order, variant, and provenance primitives; add drop-scheduling, queue/raffle, and anti-scalper mechanics as the net-new infra. Compounds community density rather than forcing a second cold-start. |
| **STL / digital files** | Shares minis' digital gnarl almost exactly (tiered licensing, membership drops, re-upload piracy where provenance is the defense); huge engaged audience. | Most contested space and **actively consolidating** — MyMiniFactory bought Thingiverse (Feb 2026), ~1M paying customers, $100M+ to creators; Cults3D, Patreon, Printables/MakerWorld all entrenched. | **Owned** (MMF / Cults3D / Patreon). | Yes (it's minis' digital half). | **Partner/coexist; do not build.** This is the file-distribution layer and it's owned. Sit alongside it: own the physical + branded storefront + cross-maker network it doesn't touch. Don't try to out-repository the incumbents. |
| **Hand-dyed yarn** | Genuinely non-fungible inventory (dye lots can't be restocked identically); dyed-to-order pre-order motion; yarn clubs = subscription drops; variant explosion (colorway × base); intense, tightly networked community (Ravelry + IG); strong anti-mass-produced ethos. | Shopify + apps already cover the storefront acceptably; **a curated demand-aggregator already exists (Indie Untangled — marketplace + newsletter + events) with a proven demand engine**; non-adjacent buyer = full second cold-start. | **Partly owned** (Indie Untangled). | No. | **Strong-but-contested; validate before committing.** Best "wide" option on gnarl and community, but the flow layer you'd want is partly occupied. Probe whether Indie Untangled has earned switching-cost loyalty or is merely lightly occupying the niche — "an incumbent exists" ≠ "an incumbent is loved." Only enter if there's a wedge it isn't serving. |
| **Custom knives** | High value per unit ($500–$800+, heirloom pieces into 4–5 figures); waitlist/lottery/deposit motion by default; finished pieces flip on a secondary market, so queue integrity and buyer verification have direct dollar value; strong collector culture. | **Entrenched decades-old curated marketplaces own the flow** (Arizona Custom Knives consignment + maker-following alerts; Noblie); blade-shipping **regulatory drag**; non-adjacent buyer. | **Owned** (consignment dealers). | No. | **Hard to displace; deprioritize.** The demand engine (maker-following, drop alerts) is already built and trusted by 25-year incumbents. Entering means dislodging earned loyalty *and* handling weapons-shipping compliance. Not a first or second move. |
| **Enamel pins** | Large audiences; campaign/pre-order (Kickstarter) motion; collectible secondary market with LE runs; B-grade/"seconds" grading is an established sub-market. | Largely a **design+manufacture (POD/dropship) business, not a craft one** — low true gnarl, factory AI pin-design tools exist; grievance is **art theft (originality), not handmade provenance** — a different, harder moat; all-in-one creator-merch layer already held by Fourthwall. | **Owned** (Fourthwall + POD). | No. | **Skip.** Weakest fit for a verified-*provenance* moat because the product isn't really handmade. The defensible problem here (originality/anti-theft) is not the one your platform is built to solve. |

### Strategic conclusion (deep vs. wide)

The scan favors **deep-and-adjacent over wide.** Dice wins on every axis *and* shares the miniatures buyer, so the arc is **miniatures → dice → broad physical tabletop** — one buyer, one community, one compounding set of drop-and-provenance primitives. Yarn and knives are "wide" bets into scenes where the exact flow layer you'd want to own is already held by an embedded member (Indie Untangled; Arizona Custom Knives) — the precise "don't fight where someone's already embedded" trap. Of the wide options, only yarn merits a validation probe before being ruled out, and the probe is specifically whether its incumbent has *earned switching-cost loyalty* or just *lightly occupies* the niche.


---

## 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 it is built for **episodic, project-scale campaigns**, not for an individual maker's **continuous drop cadence**. That distinction is the entire opening.

**The pattern:** every incumbent started exactly where this platform would — as the tool managing the gap between committed demand and delivery (pledge management: surveys, shipping, taxes, add-ons, late pledges) — then grew up into the funding layer. Kickstarter is all-or-nothing with *no* integrated pledge manager, which is the gap the others filled.

| Player | What it is | Built for | Relevance |
|---|---|---|---|
| **Kickstarter** | All-or-nothing campaign crowdfunding; ~5% + 3–5% processing; no integrated pledge manager; no installments | Episodic, project-scale campaigns | The launchpad; ~$216.6M tabletop in 2024 |
| **Gamefound** | Tabletop-native; founded by publisher Awaken Realms; evolved pledge-manager → full crowdfunding platform with late-pledge stores | Episodic tabletop campaigns + post-campaign stores | **Sitting in your adjacent vertical.** ~$84.5M tabletop in 2024, up from ~$22M in 2021 — fast-growing, Kickstarter's biggest tabletop rival |
| **BackerKit** | Pledge-manager (surveys/shipping/tax/add-ons) → also a crowdfunding platform | Post-campaign fulfillment + campaigns | ~$23.1M tabletop in 2024; "mission control" for fulfillment |

**The open gap (where to play):** none of these serve the maker running a $2k drop every other Saturday, a monthly dyed-to-order club, or a 10-piece knife lottery. Nobody spins up a 30-day all-or-nothing campaign on a biweekly rhythm. The unserved space is **continuous commitment-commerce cadence** — the recurring, relationship-driven, small-batch motion that sits *between* Shopify (continuous but stock-only) and Kickstarter/Gamefound (commitment but episodic and project-scale).

**The recurring strategic shape (same as the rest of this memo):** there is always an entrenched incumbent owning the *episodic / distribution* layer — Shopify (stock commerce), MyMiniFactory (file distribution), Gamefound (campaign crowdfunding) — and the open prize is always the *continuous cross-maker relationship* layer they don't serve. The move is identical every time: **coexist with the episodic incumbent, own the continuous demand-relationship network.** A maker can run their big annual campaign on Gamefound *and* live here for the between-campaign drop cadence — exactly as they keep STLs on MMF and physical drops here.

---

## Appendix C — Composite multi-maker kits

A kit combining products from multiple makers (dice from X, minis from Y) sold as one SKU on a maker's storefront. Powerful and on-theme — the deepest expression of maker collaboration, a natural Curated-By extension, a strong commitment-commerce "kit drop" — but it presses hardest on the one line the whole architecture defends: **custody of funds.** Two rules govern everything below. For the kit creator: **be a *principal reseller* of the kit, never a *conduit* aggregating other makers' 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 — how the kit is sold

One charge means one merchant of record and one payout destination; "one SKU, N makers, money perfectly siloed" is a contradiction. Three real models:

| Model | Mechanism | Clean? | Verdict |
|---|---|---|---|
| **1. Lead maker = MoR, others = suppliers** | A sells the kit as A's own SKU on A's own processor; A owes X/Y wholesale COGS. A is a principal reseller (bought + resold a bundle, owes the buyer the kit) — legitimate drop-ship/wholesale, **not** transmission. | Yes — single charge, single MoR, out of consumer flow | **Recommended.** The virtual-kit/BOM pattern with components sourced from other makers. |
| **2. Curated kit, no unified checkout** | Themed Curated-By bundle; each component hands off to its own store. N purchases. | Yes — fully siloed | Free but weak — N transactions in a bundle costume; buyer feels the seams. Not a true SKU. |
| **3. Facilitated split-payment** | One checkout, auto-split to N connected accounts (Connect destination charges). Shopify Collective's mechanism. | No — you become facilitator / in the flow | Cleanest *experience*; a deliberate, scoped money-flow re-entry. 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 — simplest, cleanest) or **A drop-ships** (X/Y ship directly; A never touches them but 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* of a payment that moves directly between parties (or nets on your own account as principal), never custody.

| Model | Mechanism | In the flow? |
|---|---|---|
| **A. Bookkeeper / peer-to-peer** | Platform records the payable and surfaces it; A→X money moves directly via their own arrangement. | No — cleanest, but makers chasing each other is friction that can poison collaboration. |
| **B. Net through the existing fee ledger** | Component cost becomes a ledger entry: X's receivable → credit in X's fee-offset wallet; A's payable → charge on A's next invoice. Principal on both sides (two independent events) — the same structure that kept the referral wallet clean. | No — *for the netting / non-cashable portion.* **Recommended default.** |
| **C. Connect direct payout** | Buyer pays A; platform routes component cost to X/Y connected accounts (destination charges/transfers); Stripe is the transmitter. | Yes — scoped facilitator re-entry. Cleanest experience; **B2B-first is the safest place to cross** (verified, KYC'd, mandate-on-file makers; small fraud surface). |

**Supplier choice with a carrot:** X and Y each choose **non-cashable wallet credit** (nets their own platform fees, keeps you out of the flow) or **Connect payout** (real money, you're scoped in-flow), with a **bonus for choosing wallet** — the "incentivize the clean rail" move. 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 payout regardless of bonus. Plan for both; don't expect to keep every supplier non-cashable.

**Phasing:** Phase 1 = Model A/B (record + net, settle the remainder peer-to-peer), fully out of flow. Later/optional = Model C (Connect payout) for suppliers who can't absorb wallet credit — B2B-first because it's the safest crossing.

### C.3 Fee economics — referral fee on components, taxed once

X and Y's components carry a referral fee (supplier bears it, as in Curated-By) — but **tax each kit dollar once.** Worked example: kit retails at R; agreed wholesale $40 (X dice) + $30 (Y minis) = $70 COGS to A.

- X's $40 → 15% referral fee = $6 platform; X nets $34 (wallet+bonus or Connect).
- Y's $30 → 15% = $4.50 platform; Y nets $25.50.
- A pays the standard platform fee on **A's own margin (R − $70)**, *not* on the full R.

Charging A's full platform fee on R *and* referral fees on the components would double-tax the $70 (the same "don't stack to ~19%" trap as the referral discussion). All of it runs through the ledger off the order event — never through the consumer payment, since A is MoR for the retail sale.

### C.4 Where kits can be sold — the constraint is inventory integrity, not fees

The fee-and-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 `orders/create` webhook.** Shopify doesn't block the money model. What it can't give you is a **real-time cross-maker stock check at purchase** (you don't control its checkout), so finite-stock components have a sync-lag oversell window. Therefore:

- **Finite-stock multi-merchant kits → favor your Medusa storefront** (you control checkout: atomic component-availability gate + atomic order+payable creation).
- **Made-to-order kits → storefront-agnostic, including Shopify** (no finite-stock race; kit lead time = max of component leads = pre-order semantics you already have). Dice/minis are frequently made-to-order, so this is the common case, not a corner.
- **v1 scoping:** launch kits as a Medusa-seller feature (native BOM, real-time inventory, atomic settlement); optionally allow made-to-order kits for Shopify sellers; defer Shopify-seller *finite-stock* kits as the hard later extension.

### C.5 Wholesale bookkeeping — including volume tiers

Storing "X charges A $W/unit, tiered by volume" and computing settlement from units sold is **pure facilitation (out of flow)** — virtual-BOM/COGS with a cross-maker settlement twist. Two design details volume tiers force:

- **Retroactive vs. prospective tiers:** when X's price drops at unit 11, do units 1–10 reprice or only 11+? This is a *term A and X agree to*; the platform stores and applies it.
- **Stateful settlement:** tiered pricing depends on cumulative units over a window, so settlement is a running total per supplier-agreement, not per-order-independent. Build the ledger for stateful supplier agreements 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, especially jarring on a "deal" kit), on **A** (absorbed into price — uncontrollable margin variance), or on **suppliers** (baked into wholesale — inflates COGS, shrinks A's margin). For low-AOV components, per-parcel shipping can rival the component cost. No free placement — it attacks the "kit is a deal" proposition directly.

Managing it, best to worst:

1. **Assemble-and-consolidate (default).** Components ship to A; A packs one box; one shipping cost. The stock variant of Model 1 — and it fixes **three** problems at once: single shipping cost, single-package buyer experience, and QC (A inspects components → resolves the "who owns a miscast mini" liability). Cost: A handles inventory + assembly (a micro-fulfillment role) — but that *is* the value A adds, and it justifies A's margin.
2. **3PL / hub consolidation.** A partner consolidates; cleaner for A but adds a third party and cost — overkill at indie-maker volumes. Defer.
3. **Honest drop-ship.** "Ships in N packages," higher combined shipping disclosed up front. Reserve for when consolidation is genuinely impossible; accept the conversion hit and multi-package experience.
4. **Shipping-smart kit construction (a lever regardless of model).** The platform surfaces estimated combined shipping *at kit-design time*, prefers same-region makers, and warns when a kit's combined shipping blows its value prop. Your network sees cross-maker shipping geography no single maker can — turning a hidden checkout cost into a visible design constraint.

**Consolidation vs. made-to-order is a real knot:**

| 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; A runs a multi-supplier pre-order with an assembly stage |
| Made-to-order | Drop-ship | N boxes, N arrival times, N shipping charges — **worst case; avoid unless unavoidable** |

**Through-line:** shipping doesn't argue against kits — it argues that the kit creator should be a real **assembler-principal**, not a thin aggregator of others' drop-shipments. A's justified value and margin *is* that A sources, settles, consolidates, QCs, and one-boxes a thing no single component maker offers. 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 for network participation 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/sovereignty). Merchant-controlled storefronts grant all three; walled-garden marketplaces deny all three *by design* — the intermediation of the buyer is the marketplace's business model (retail media, ads, the take on a captive relationship), so a marketplace that let an external network embed, attribute, and own the buyer would be dismantling its own asset. Participation therefore **degrades monotonically as a maker cedes control to a walled garden.**

**Layered on top is a value-system rule that is stricter than the technical limits: the network never routes buyers *into* a walled garden — not via Curated-By, not via the buyer feed, not via the agent feed.** Every such link would lend the community's trust to the captive-commerce model this enterprise is an alternative to. So walled-garden makers are **invitation targets, not network destinations** — even where a marketplace's API would *technically* permit ingesting their catalog, the value rule forecloses surfacing it as a buyable destination. (This supersedes an earlier draft that treated Etsy sellers as inbound "discovery receivers"; sending buyers to an Etsy listing is exactly the outward-pointing pattern now ruled out.)

### Participation matrix (ordered most-control → least)

Legend: ✓ supported · ◐ partial/limited · ✗ not supported.

| Provider | Catalog sync-in | Be a curator (host the collection) | Be a network destination (Curated-By / feed / agent) | Clean referral-fee attribution | Owns buyer (sovereignty) | Clean agentic checkout |
|---|---|---|---|---|---|---|
| **Your white-label storefront (Medusa)** | ✓ native | ✓ you build the page | ✓ controllable + value-OK | ✓ you own checkout | ✓ shared auth, maker owns relationship | ✓ you expose ACP endpoints |
| **Self-hosted (WooCommerce, 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 app block | ✓ controllable + value-OK | ✓ cart attr → order webhook (any plan) | ✓ merchant owns customers | ✓ their processor (deep checkout = Plus) |
| **BigCommerce** | ✓ Catalog/Admin API | ✓ open storefront (widgets/headless) | ✓ controllable + value-OK | ✓ controls checkout (Open Checkout) | ✓ owns buyer | ✓ their processor |
| **Squarespace / Wix** | ◐ commerce APIs (read) | ◐ code-injection / Velo, no clean app-block model | ✓ controllable storefront, value-OK | ◐ checkout more closed — coupon/landing only | ✓ owns buyer | ◐ depends on platform support |
| **Etsy** | ◐ Open API v3 (OAuth, commercial access) — *but unused as a destination by value rule* | ✗ can't modify the Etsy page | ✗ **value rule** — would route buyers into a walled garden; invitation target only | ✗ Etsy owns checkout (coupon-code at best; moot) | ✗ Etsy owns the buyer | ✗ Etsy's decision; routes into Etsy |
| **eBay** | ◐ Sell/Trading APIs (read) — *unused, as above* | ✗ can't modify the listing page | ✗ value rule (walled garden); invitation target | ✗ eBay owns checkout | ✗ eBay owns the buyer | ✗ eBay's decision |
| **Amazon Handmade / Amazon** | ✗ SP-API is gated/restricted for this | ✗ zero storefront control | ✗ value rule + Amazon owns everything; invitation target | ✗ Amazon owns checkout | ✗ Amazon owns the buyer (most completely) | ✗ Amazon's own agents (Rufus / "Buy for Me") treat you as a competitor |

The table's shape *is* the thesis: **controllable storefronts are ✓ across; walled gardens are ✗ across.** That's not a coverage gap — it's a restatement of who the network is *for* (makers who own their commerce, or will) and what it's an alternative *to* (captive marketplaces).

### The three-surfaces gate, explained

- **Storefront-page control → be a curator.** Hosting the verified merchant referral collection requires injecting a UI block into the maker's own page. Controllable storefronts allow it (native, app block, widget, code); walled gardens don't expose the page.
- **Checkout control → attribution + agentic checkout.** Billing a referral and running a clean agent purchase require instrumenting the cart/checkout. Controllable storefronts let you (cart attributes, your own processor); walled gardens own checkout and strip your attribution.
- **Buyer-relationship control → sovereignty/identity.** Owning the buyer (the basis of the cross-maker identity layer) requires the maker not be intermediated. Walled gardens own the buyer by definition.

### Walled gardens are who you're an alternative to — not a gap to cover

A maker deep in Amazon Handmade who can't participate isn't missing coverage — they're the person the pitch is *aimed at*, who hasn't left the garden yet. The model not working *inside* the walls is consistent with the model being the way *out* of them. So the right move toward walled-garden makers is **invitation, not integration**: "I'd feature your work in the network the moment you own your commerce." The *absence* of a link is the recruiting signal — it makes membership (on a controllable storefront) the price of inclusion rather than subsidizing captivity with free audience.

### Notes on the marketplaces

- **Etsy is the most permissive walled garden** — Open API v3 (OAuth 2.0, `listings_r`/`transactions_r`, commercial access subject to review) can read listings and receipts, it natively models made-to-order (`readiness_state`), and it even runs an affiliate program that blesses inbound links. None of that changes the conclusion: the value rule forecloses using Etsy as a buyable destination, so its API permissiveness is moot for participation. (A maker on *both* Etsy and a controllable storefront participates via the controllable storefront; their Etsy presence is simply ignored.)
- **Amazon Handmade is the most walled and the most hostile** — restricted/gated API access, zero storefront control, the most complete buyer ownership, and Amazon's own agentic-commerce ambitions (Rufus, "Buy for Me") mean it would view a verified-supply network as a competitor to route around, not a partner to ingest. Your assumption is correct: this model can't run on Amazon Handmade, and shouldn't try.

### The verification inversion (as a recruiting angle)

Walled gardens are the polluted marketplaces this strategy reacts against, so you verify makers **independently of any marketplace's compromised "handmade" badge.** That inversion is now a *recruiting* message rather than a participation tier: "we'd vouch for your work — verified independent of Etsy's badge — the moment you own your commerce and can be a real member." You become the trust layer the marketplaces stopped being, *for the makers who leave them.*
