Button Master Plan — Affiliate Infrastructure on Commerce Rails (Rollout Plan)

Anchor: 00 · What Button Is · Thesis: B2 · Opportunity Thesis · Product: usebutton 2.0 Spec · Pipeline: Master Pipeline

The thesis in one line

Commerce rails are the ground; affiliate infrastructure is the layer Button builds on top. Amazon, Shopify, and raw links are where transactions happen. Button becomes the universal membrane that makes any link across any of those rails trackable → attributable → monetizable → optimizable — one creator identity, one attribution truth, many rails.

The rail model — what "on top of commerce" means concretely

Each commerce rail has a native affiliate/tracking primitive. Button's job is to abstract them into one layer so a creator never touches the rail's plumbing.

The pattern is a Rail Adapter: a pluggable module per commerce rail that speaks its native affiliate API and normalizes it into Button's universal link + attribution model. Adding a rail = writing an adapter, not rebuilding the core. This is the architectural key to "infrastructure."

Rollout — five phases

Phase 1 · Amazon rail hardened (the beachhead) · 🟡 FIRST

Amazon is where the evidence and the creators already are. Prove the abstraction on the hardest rail first.

• BD-01 Browser Plugin — one-click trackable Amazon link → Button DB, creator/Button tracking IDs only, fail-closed on teka000-20. BuildDoc

• Amazon Rail Adapter v1 — normalize Associates tracking IDs + PA-API product resolution into the universal link model.

• Creator link library — every generated link registered, attributable, visible in the portal.

• Exit criterion: a creator generates and tracks an Amazon product link in one click, end to end, no manual Associates work.

Phase 2 · The universal link + attribution core · ⚪ NEXT

The rail-agnostic spine every future rail plugs into.

• Universal Link Service — one link primitive, rail-tagged, that resolves to the right rail adapter.

• Creator Identity layer — one creator identity across rails (the thing no single rail gives them).

• Attribution ledger — the tracked-commerce truth (Orchestrate line from B2 — wire to / respect Button's existing PostTap engine, don't re-implement).

• Funnel Builder (BD-02) rides on top — multi-step journeys across rails. BuildDoc

Phase 3 · Shopify rail · ⚪ QUEUED

The second rail proves the adapter pattern generalizes beyond Amazon.

• Shopify Rail Adapter — Collabs / affiliate-app / checkout attribution normalized into the universal model.

• Cross-merchant creator identity — a creator's Button identity works across every Shopify store, not per-merchant silos.

• Strategic weight: this is the moment Button stops being "an Amazon/mobile thing" and becomes rail-agnostic infrastructure.

Phase 4 · Creator + Rep operating surfaces · ⚪ QUEUED (parallelizable with 2–3)

The two-portal app from the product spec, now understood as the human surface over the rail infrastructure.

• Creator portal (BD-03) — upload to opted-in campaigns, overlays within parameters, links from any rail. BuildDoc

• Rep portal (BD-04) — campaign management, approval, parameters, RBAC. BuildDoc

• Public marketing surface — Fable-level, SEO/GEO, GH+Vercel (drives 01 Brand / 02 Design).

Phase 5 · The agent-native expansion · ⚪ HORIZON

Where Button goes past what its current architecture can reach (B2 expansion frontier).

• Agent-native deal desk — source → qualify → draft → configure deals behind a human gate.

• Conversational-commerce / MCP surface — Button attribution + Cloud commerce MCP → AI shopping agent that recommends and routes with attribution intact across rails. (Sits on the `teka000-20` seam → fail-closed boundary applies.)

• Self-serve long-tail — productize Phase-1 onboarding so mid-market/long-tail creators self-onboard, expanding TAM.

• GEO-as-infrastructure — Button as the attribution layer behind AI-answer-engine commerce recommendations.

Sequencing logic (why this order)

1. Amazon first because the creators, the evidence, and the hardest constraints are already there — if the abstraction works on Amazon's individual-product-link mess, it works anywhere.

2. Universal core second so Shopify (and every future rail) plugs in instead of bolting on.

3. Shopify third as the proof the infrastructure claim is real, not Amazon-specific.

4. Portals fourth but parallelizable — the human surface can build alongside the rails once the universal link exists.

5. Agent expansion last because it compounds on everything below it — you can't have an agent deal-desk over rails that don't exist yet.

Build-fleet mapping

All repo-bound builds wait on: (a) the GH+Vercel scaffold, and (b) your review of B2. Ora vets; Daniel taps merge.

Open inputs before Phase 1 dispatch