usebutton 2.0 — Product Spec (the rebuilt app)
usebutton 2.0 — Product Spec (the rebuilt app)
The umbrella spec for the full rebuild. Two unified portals (retailer/rep side + creator side), built on GH+Vercel with The Cloud as ops substrate. Every feature BuildDoc below nests here. This is the "what we're building" — the phased builds are the "how."
Anchor: 00 · What Button Is · Onboarding evidence: PostTap Creator Onboarding Flow · Pipeline: Master Pipeline
The two surfaces we're building (unified in one app)
1. Rep / Retailer / Advertiser panel — Button reps manage campaigns, set parameters, approve content, and set per-campaign strictness. Retailers/advertisers configure product networks and funnels.
2. Creator panel — creators authenticate (Login with Amazon), generate trackable links (via the browser plugin), upload content into campaigns they're opted into, and customize overlays within campaign parameters.
Feature builds (each its own BuildDoc)
BD-01 · Browser Plugin — one-click trackable link. On any product page, a creator/user clicks and a trackable link is created in their Button DB / registered against their tracking ID. Removes the manual Amazon-tracking-ID + individual-product-link friction (see onboarding evidence step 2). → BuildDoc
BD-02 · Funnel Builder. usebutton 2.0 gives retailers/advertisers a way to create funnels — multi-step journeys from ad → product → conversion, wired to Button's attribution. → BuildDoc
BD-03 · Creator Content-Upload + Overlay Conformance. In the creator panel, creators upload content to the specific campaigns they're opted/accepted into, pick overlays to customize, but must conform to campaign parameters. Some campaign content is free-for-all; some is stricter / needs approval. → BuildDoc
BD-04 · Rep Campaign Management, Approval & Parameters. Button reps get access to manage campaigns, approve content, and set parameters + strictness tiers (free-for-all / approval-required). → BuildDoc
(Links fill in as each BuildDoc is filed below.)
Cross-cutting requirements
Fable-level design + SEO/GEO on the public marketing surface (drives from 02 · Design Audit).
The Cloud as ops substrate — campaigns, creators, approvals, and parameters live as Cloud primitives where it makes the ops loop tighter.
Ecosystem-respecting — must keep Button's integrations (impact.com, Rakuten, APS/Amazon) intact; don't wall the platform off (per Lane A Evidence).
GH + Vercel build target, per Daniel's locked decision.
Agent workflow segmentation (how the fleet builds this)
BuildDoc | Nature | Model tier | Lane |
|---|---|---|---|
BD-01 Browser Plugin | Novel (extension arch, auth, DB write) | Frontier | Design spike → repo-bound build |
BD-02 Funnel Builder | Novel logic + UI | Frontier | Spec → repo-bound build |
BD-03 Creator Upload/Overlay | Mixed (UI mechanical, conformance-logic novel) | Frontier for logic, native for scaffold | Repo-bound |
BD-04 Rep Mgmt/Approval | Mostly CRUD + RBAC (Kindo RBAC pattern reusable) | Native scaffold, frontier for parameter engine | Repo-bound |
All repo-bound builds wait for the GH+Vercel scaffold + Lane B thesis review before dispatch. Ora vets; Daniel taps merge.
