Files

T

ben.stull 275d760aeb docs: add §10 open-sections backlog to maker platform strategy

Records the seven undeveloped operational axes (trust & safety, demand
GTM, legal/compliance, sustainability economics, MVP scope, data model,
governance) in rough priority order, each flagged as a future session.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-06-15 04:38:37 -07:00

76 KiB

Raw Blame History

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.

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.

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

A clean, portable, verified catalog data model that you own. Cheap to do well now, expensive to retrofit later.
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.
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 — the maker stays merchant of record, Stripe is the transmitter, and you take an application_fee per transaction without holding funds. (Verify the liability split across account types with Stripe's docs and a payments attorney before architecting — it varies by type. Not legal advice.) But the default money model is the out-of-flow ACH/invoice fee below, with Connect reserved for the deliberate later crossings (cashable wallets, kit/taste-maker payouts).

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.

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

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.

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, cross-maker identity/follow graph, 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.

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

Trust & safety / maker accountability (post-verification) — highest priority, moat-critical. Verification is currently only an entry gate; the doc is silent on what happens when a verified maker behaves badly afterward. Commitment commerce makes this the signature failure mode: taking money before delivery means "verified maker collects pre-orders/deposits and ghosts" is the structurally most-likely scam, not an edge case. The money-flow stance solved the financial exposure (maker is MoR) but not the reputational one — a verified maker scamming buyers detonates the verification guarantee the whole moat rests on. Needs: verification-revocation triggers and process; a buyer-harm/dispute framework; a buyer-protection stance (mediate? warn? nothing?); how revocation propagates through the peer-verification graph (slashing the voucher); non-delivery handling given you're deliberately not in the flow.
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.
Legal & compliance, consolidated — especially marketplace-facilitator sales tax. The scattered legal points (MTL, raffle/lottery, GDPR/CCPA, FTC disclosure) need one consolidated section, and sales-tax / marketplace-facilitator nexus is entirely absent and high-consequence: facilitator statutes can attach tax-collection duties to a "marketplace" even when you're not the merchant of record, and the trigger is often "facilitating the transaction" — which referrals, kits, and a Phase-3 shared checkout could implicate. The staying-out-of-the-flow stance feels like it should cover this but doesn't. Also restore the freedom-to-operate / patent check and the "is this novel" competitive finding (components exist, combination is novel-but-unproven) that didn't survive generalization.
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.
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.
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.)
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.

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.

Model	Mechanism	In the flow?
A. Bookkeeper / peer-to-peer	Platform records the payable; A→X money moves directly.	No — cleanest, but makers chasing each other is 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. Recommended default.
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: each supplier chooses 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 + 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.
Verification gates the demand, not the tool — which makes makers chase it 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.

76 KiB Raw Blame History Unescape Escape