Miniatures strategy generalized to makers and condensed/consolidated
This commit is contained in:
@@ -0,0 +1,446 @@
|
||||
# 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.
|
||||
|
||||
1. **Tool.** The verified-maker commitment-commerce engine with a white-label storefront as its surface — genuinely the best home for a real maker. Useful at zero liquidity. Accrues supply, a structured provenance-stamped catalog, *and* a base of drop-followers. *A real business even if the network never lights.*
|
||||
2. **Community.** Narrow to one craft scene tight enough that word-of-mouth substitutes for a marketing budget (the beachhead). Add cross-maker discovery with an editorial point of view — the demand-generating feature you build rather than buy.
|
||||
3. **Marketplace.** Light the curated cross-inclusion network once supply density and community exist — it *emerges* from accumulated follows (§7), rather than launching cold into the graveyard.
|
||||
4. **Infrastructure.** Expose the verified-supply graph to agents; become the rails.
|
||||
|
||||
**Selection criterion that decides everything:** pick the community where you show up as a *member, not a vendor* — where you already have, or can authentically build, real standing.
|
||||
|
||||
---
|
||||
|
||||
## 6. The immediate engagement (the first makers)
|
||||
|
||||
A good investment **if** you build the right common infra. The wasted version is a generic storefront engine ("the same as Shopify") — the stock layer, valueless in every branch.
|
||||
|
||||
The reusable assets worth owning, none of which is a storefront builder:
|
||||
|
||||
1. **A clean, portable, verified catalog data model that you own.** Cheap to do well now, expensive to retrofit later.
|
||||
2. **The commitment-commerce primitives (the engine)** — scheduled drops, pre-orders/deposits, raffle/queue allocation, recurring clubs/memberships, made-to-order workflows, digital delivery + licensing, variant/bundle handling. The portable, vertical-spanning core; the storefront is just its surface.
|
||||
3. **Standing in the beachhead community** and the first reference relationships.
|
||||
|
||||
**Operating rule: build the maker-shaped 20%; rent the 80%.** Use a template, headless setup, or even Shopify itself for the commodity storefront parts. Let this be paid consultancy whose real return is knowledge, references, and a portable data asset — a cheap option on the bigger play.
|
||||
|
||||
---
|
||||
|
||||
## 7. Architecture
|
||||
|
||||
The money-flow stance and the first network feature turn out to be the same decision viewed twice; the rest of the section builds out from there.
|
||||
|
||||
### Money flow: stay out of it (the "no")
|
||||
|
||||
The white-label model enforces this: each storefront is the maker's brand on the maker's own payment processor, so **the maker is merchant of record by construction.** The money never touches you — you sell software, they run commerce. This is *cleaner than Kickstarter*, which is itself in the money flow (processes pledges, takes a cut, pays out) and only disclaims *delivery* liability; here you avoid both the flow and the delivery liability structurally.
|
||||
|
||||
**Why staying out is right:** no money-transmitter/escrow licensing (holding customer funds triggers state-by-state MTL in the US); no chargeback exposure (it hits the maker's processor, not you); no delivery-risk balance-sheet exposure; clean SaaS margins and a faster launch; and it's maker-aligned (their brand, processor, payouts, customer, data). The cost is forgoing payment take-rate — but that's exactly the slice that carries the risk you're declining, a fair, deliberate trade. The cross-maker identity moat doesn't need checkout anyway: **the asset lives at the *follow*** ("who follows which makers and commits early"), captured at the account / "notify me" / club layer you own regardless of whose processor runs the charge.
|
||||
|
||||
If you ever want transaction economics without the MTL burden, **Stripe Connect** is the middle path — 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.
|
||||
|
||||
### Customer ownership, consent & martech
|
||||
|
||||
"Own the customer" creates an obligation: consent has to be managed somewhere, and *where the source of truth lives* decides whether the promise is real or a disguised lock-in. The governing test: **if this maker left tomorrow, could they fully and lawfully market to their consented customers without ever touching the network again?**
|
||||
|
||||
**Source of truth: the maker's own ESP — not the network.** For a maker's *own* marketing, the maker's ESP (Mailchimp, Klaviyo, …) is authoritative and the network is a thin integration layer. This is *more* sovereign and *simpler* than a network ledger, passes the leave-tomorrow test tautologically, and dissolves the orphaned-opt-out-link problem: the unsubscribe link resolves to the ESP's native hosted unsubscribe, which the maker keeps after departure.
|
||||
|
||||
- The network captures email + per-type marketing consent at checkout and **pushes the subscriber to the maker's ESP**; the ESP owns everything after (compliant unsubscribe, suppression, deliverability).
|
||||
- Opt-outs happen in the ESP; the network **reflects them via the ESP's unsubscribe *webhooks*** (prefer webhooks to polling). The network is a connector, never an ESP.
|
||||
- **Imported pre-existing lists** then need no special handling — they live in the maker's ESP, naturally arm's-length from the network's records.
|
||||
|
||||
**Two consent domains — only one belongs in the ESP.** *Maker-originating* marketing → the maker's ESP is authoritative. *Network-originating* communications (buyer feed, aggregate marketing emails below, follow notifications) are the network's own relationship with the buyer, governed by **network-communication consent** the network must own. Keep them strictly separate: **the network may never borrow a maker's ESP list for its own sends.** "Send A's curation to A's buyers" means *A's buyers who also opted into network email* — the overlap, never A's whole ESP list.
|
||||
|
||||
**The cross-maker buyer dashboard is a thin cache + fan-out, not a ledger.** With consent scattered across N ESPs, the unified dashboard ("manage all my subscriptions," "opt out of all promotional across all makers") needs a **read cache** (webhook-synced reflection — explicitly *not* the source of truth) and **fan-out writes** into each maker's ESP. Per-*maker* full unsubscribe is easy everywhere; **per-*type* across makers is the fiddly part** (each ESP models promotional-vs-drop differently — groups/tags/interests/lists — so your normalized type taxonomy must map onto each). Every dashboard control writes per-maker (per-type) records; a buyer-level standing preference ("never promotional from anyone") acts as a *default that generates per-maker records as new consents form*, not a send-time global override.
|
||||
|
||||
**Greenfield fork: no ESP → network light-sending is the temporary source of truth.** Greenfield makers (the two interviewed) have no ESP, so the network provides **optional light first-party sending**, where it *is* authoritative because no ESP exists. Keep it deliberately minimal (never a Klaviyo competitor) and **exportable to seed a real ESP later**. The graduation path is the right shape: greenfield → grows → adopts an ESP → the network steps *back* from authority to integration. Network involvement *shrinks* as the maker matures.
|
||||
|
||||
### The network marketing channel (aggregate emails & email-embedded curation)
|
||||
|
||||
Distinct from maker-originating ESP email, the network runs its **own** marketing channel — a discovery engine, provided it obeys the feed discipline.
|
||||
|
||||
- **Personalized aggregate emails.** The network emails buyers (on the **network's** consent list) digests aggregating content/deals from *multiple* makers. The hard rule that keeps this from becoming retail-media-by-email: **content traces to the buyer's own engagement graph** — drops/deals from makers they follow, plus those makers' Curated-By picks — and the network *aggregates, personalizes, and delivers* (pipe) but **never injects platform-chosen merchants or sells placement.** Maker-as-discovery-engine, platform-as-pipe.
|
||||
- **Two-sided opt-out, both network-owned:** buyers opt out of receiving network marketing; makers opt out of being *included* in it.
|
||||
- **Curation as living discovery.** A buyer who engaged with Maker A can receive A's *current* Curated-By picks in their network digest, and as A's curation evolves the fresh picks flow into emails to A's (network-consented) buyers — turning Curated-By into a *recurring* discovery surface for the makers A vouches for, through the channel the network legitimately owns.
|
||||
- **Curated-By as an email widget in the maker's own ESP.** Makers embed their live Curated-By block in their own newsletters, with links carrying the stateless referral token — so a maker's own newsletter becomes a referral-generating surface (they earn credit; attribution works without identity). Points only to verified makers on controllable storefronts; reputation-staked, not paid; and — since email can't run JS — the widget is a send-time-pulled HTML block or a server-rendered image (refreshed per send).
|
||||
|
||||
### Verification: the gate to the trust tier
|
||||
|
||||
Verification sits at the boundary between the commodity layer and the moat layer. Three states, not two:
|
||||
|
||||
- **Unverified → full SaaS, zero network.** Any maker gets the complete commitment-commerce storefront (drops, pre-orders, clubs, own processor) — a paying customer of a genuinely good tool, but in *nothing* trust-gated (no referrals, no Curated-By either direction, no buyer feed, no agent feed). The storefront is commodity; gating it would suppress the Phase-1 wedge. Let everyone in the front door.
|
||||
- **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.
|
||||
|
||||
---
|
||||
|
||||
## 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.
|
||||
Reference in New Issue
Block a user