Barber Affiliate OS

§1Context

Classic Barber Products is a wholesale barber supply distributor in Temecula CA — roughly 4,500 barbershop accounts across the U.S. carrying premium men's grooming brands (Slick Gorilla, STMNT, Brosh, Lockhart's, Captain Fawcett, Barbicide, Suavecito, Cape Gang, Holy Black, Rascal). We pitched them a "Tri-Fold Business OS" in March 2026 — public storefront rebuild, wholesale client portal, admin command center — with B2B affiliate referrals included as a Phase 4 stretch goal. That deck is live at cbp.robobffs.site, awaiting final UX/pricing review from Wally.

Mike has now brought a new pitch back from a recent conversation with Brian: a list-share affiliate program that's a fundamentally different product than the affiliate piece in our prior deck. Brian is reportedly in active discussions with a developer who built and successfully exited a vertical-SaaS product to a larger payments/platform company — the exact app and acquirer aren't confirmed, but the relevant detail is the same either way: this is a senior builder with a successful exit on his resume, which means he'll likely propose equity, profit-sharing, or premium hourly billing.

This brief reconciles the two affiliate models, identifies what we need to confirm before scoping, and frames our go-to-market positioning against the senior-dev competition.

§2Two Affiliate Models — Reconciliation

The "Affiliate OS" we already pitched in Chapter 8 of the CBP deck and the "Affiliate OS" Mike described at lunch are different products with different surfaces, economics, and risk profiles.

Working assumption — lunch model is the lead

• Mike's account was specific and consistent — 30% commission, list-share via booking platforms, per-barber branded marketing
• Brian is shopping the work to outside developers, which only makes sense if the ask is meaningfully bigger than what we already pitched
• The 30% number tracks with consignment economics, not affiliate referral economics
• "Brand the emails per barber" is a real engineering constraint, not afterthought

Both models could coexist inside one OS (referral affiliates and list-share affiliates as two affiliate types), but this brief assumes the lunch model is the spine until Brian confirms.

§3The Lunch Model — System Concept

Thesis

Most independent barbers are sitting on customer contact lists collected through booking platforms (Squire, Booksy, Schedulicity, Acuity) that are not being monetized. Barbers are generally not strong retail sellers and don't want to carry inventory. CBP wants to:

1. Receive list contributions from participating barbers
2. Run retail marketing campaigns (email V1, SMS V2) branded as the barber to those lists
3. Fulfill resulting consumer orders directly through CBP
4. Pay the contributing barber 30% of attributable revenue
5. Track, account, and operate the entire program through a purpose-built OS

What the OS actually contains

Rough decomposition — seven coordinated subsystems:

Load-bearing design constraints

These shape the architecture from day one — not features that get added later.

• Consent / compliance. Barbers' customers consented to communications from the barber, not from CBP. CAN-SPAM (email), TCPA (SMS — much stricter), and state privacy laws (CCPA, CPA, CTDPA, VCDPA) make naive list-sharing legally radioactive. The architecture must use a "send on behalf of barber" pattern (detailed below) where the barber is the legal sender and CBP is the service provider. Get this wrong and one complaint can kill the program.
• Multi-tenant data isolation. Per-barber list scoping affects unsubscribes, data subject requests, audit trails, and what happens when a barber leaves the program.
• Attribution durability. Customer lists overlap (same end-customer at multiple shops). The attribution model has to be defensible enough to pay commissions without disputes.
• Booking platform TOS. Squire and Booksy may not permit bulk list export by the barber under their terms. Worth verifying before we promise automated ingest.
• Consumer fulfillment ops. CBP today ships wholesale to barbershops. DTC single-unit orders, returns, and customer service is a different operational muscle — confirm CBP has it or plans to build it.

Compliance architecture — how CBP stays clean

This is the legal model that powers Mailchimp, Klaviyo, Postmark, and every legitimate co-branded marketing platform. It's well-trodden ground. Five pillars, in order:

What we build vs. what counsel drafts

• CBP + privacy counsel drafts: Affiliate Agreement, Data Processing Addendum, privacy policy updates, consent attestation language. We do not try to be the lawyer.
• Robot Friends builds: the OS plumbing that makes the architecture enforceable — per-barber sender domain provisioning, attestation workflow at ingest, scoped unsubscribe handling, audit logs, suppression at send-time, complaint-rate monitoring, warmup automation.

SMS is a separate, stricter conversation

TCPA requires prior express written consent for marketing texts and email-only consent does not transfer. SMS belongs in V2 with its own dedicated re-permission flow. Plaintiff-firm activity around TCPA class actions is high — under-engineering this is the fastest way to put the program at risk.

§4Discovery Call — Question List

Six clusters, twenty-two questions. Order matters — the first cluster establishes whether the rest of the conversation makes sense.

Reserve questions if time permits

• Existing tools to integrate with — QuickBooks, Klaviyo, ShipStation, Stripe Connect for payouts
• Reporting cadence Brian wants weekly / monthly
• Hosting and data residency preferences
• V1 launch timeline target

§5Strategic Risks

The risks worth flagging before we quote anything.

§6Our Positioning

Three differentiators that will actually matter to Brian, ranked by weight in the decision.

1. Operator-friendly economics. 40-60% cheaper than a senior full-stack dev. No equity ask. No profit-sharing. Brian buys the system once and owns it. This is the lead — most ex-acquired devs propose equity or rev-share because that's what worked for them last time, and a lot of operators are tired of giving away upside.
2. Warm relationship + prior pitch context. We've already mapped CBP's brand, voice, and operations through the CRO engagement. Reduced ramp, lower discovery cost, lower risk of the build veering off-spec.
3. Demonstrable design + product quality. Senior devs typically ship competent but visually unimpressive product UIs. We ship a clickable demo at premium SaaS tier (Linear / Stripe / Vercel-grade) before any work is paid for. They show resume; we show product.

§7Proposed Demo Concept

Full demo build spec lives in a separate planning doc; key beats here.

Four surfaces that tell the whole story end-to-end

1. Admin dashboard. CBP's home — ecosystem metrics, top performers, "Launch campaign" CTA in the header.
2. Campaign builder. Segment selection → template pick → preview → mock-send. Demonstrates the marketing engine without firing real mail.
3. Per-barber branded email preview. Side-by-side: same campaign, two different barber brand wraps. The "aha" moment.
4. Affiliate portal. Single barber view — list performance, attributed revenue, commission ledger, pending payout.

Build choices

• Lunch model, not deck model — list-share consignment, not B2B referrals
• CBP-real product names seeded into mock data — Slick Gorilla, STMNT, Brosh, Barbicide, Suavecito — so email previews feel real instead of obviously mocked
• Generic "Affiliate OS" shell branding wrapping CBP-skinned content inside — reusable for future prospects
• Elevated visual aesthetic — heritage-barbershop direction executed at premium SaaS tier; implicitly demonstrates what CBP's marketing surfaces could look like at higher visual taste, without naming the comparison
• Wow-tier polish — Magic UI, Aceternity, custom motion design, careful typography (Fraunces + Geist), editorial spacing
• Password-gated, deployed to Vercel — Mike hands Brian a URL

§8Sequencing

1. Brief reviewedby Richard, then optionally circulated to Wally (open thread from prior CBP engagement).
2. Demo build2–3 days at wow-polish tier. Separate repo, generic Affiliate OS naming, deployed and password-gated.
3. Discovery call with Brianquestions in §4 as the spine; demo as the closer. Aim to confirm lunch-model assumption in the first 5 minutes.
4. Scoped proposalinformed by call answers; structured in phases (MVP launch → V1 → V2). Paid engagement, no equity, clean ownership transfer.
5. DecisionBrian engages or doesn't. Either way, the demo shell becomes a re-pitchable asset for other distributors.

§9Open Items for Richard

• Confirm lunch-model-as-lead assumption (working assumption: yes)
• Decide whether to ping Mike to verify the senior dev's actual app/exit before discovery call (low-stakes, but tightens our positioning if cited)
• Decide whether Wally sees this brief before the demo build kicks off, or after
• Confirm demo build location: C:\Dev\_PROJECTS\_CLIENT-PROJECTS\affiliate-os\ — new repo, generic name
• Confirm whether to pull live CBP product photography for the demo, or generate elevated editorial product shots fresh
• Confirm whether a client-safe version of this brief is also wanted (this version is internal — strategic-positioning and competitive-risk language is too sharp for Brian's eyes)
• Counsel engagement — Brian needs to engage privacy/marketing counsel to draft the Affiliate Agreement + DPA. We can recommend specialists if needed (firms experienced with CAN-SPAM / TCPA / state privacy work), but we don't draft the documents ourselves. This should be flagged at discovery as a parallel workstream so the legal isn't a launch blocker.
• Email infrastructure choice — Postmark, SES, SendGrid, or Mailgun for the per-barber DKIM subdomain architecture? Affects build cost + deliverability ceiling. Default recommendation: Postmark (best deliverability, clean API for multi-domain) or AWS SES (cheapest at scale).