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.

Recommended addition — Booking system as bundled benefit

Bundle a free booking capability into the affiliate program for participating barbers. The booking layer isn't the headline product — it's the bundled benefit that makes the affiliate ask irresistible AND solves three independent problems at once:

• Booking platform TOS problem dissolves. If barbers book through CBP-provided infrastructure, there's no Squire / Booksy export issue to solve. Data flows natively.
• Operational scaling problem dissolves. CBP doesn't chase 4,500 shops for monthly list refreshes. Customer data is ambient — every new booking enters the system automatically.
• Retention becomes a moat. Barbers don't quit the affiliate program because leaving means losing their booking platform too. Switching cost = lock-in.
• Behavioral data unlocks dramatically better marketing. Bookings capture service type, frequency, recency, and no-show patterns — not just contact info. Triggered campaigns ("It's been 5 weeks since your last cut at Marco's — here's a beard balm Marco recommends") convert dramatically better than scheduled blasts. This is the quiet upside that doesn't show up in the obvious value prop.

What it costs CBP

A booking system is a real product, not a feature. Calendar conflict resolution, recurring appointments, deposits / no-show fees, SMS reminders, payments, staff scheduling, walk-in queue, calendar sync (Google / Apple) — each is a sub-product. Squire and Booksy have years of polish. Building a credible head-to-head competitor outright is 6-12 months of focused work plus an ongoing operational burden (Twilio bills, calendar API costs, support tickets when bookings break).

The "free for affiliate members" framing also commits CBP to subsidizing infrastructure indefinitely. The unit economics need modeling before we promise it — at what attach rate does the booking infra cost still leave room for the 30% commission and CBP's margin?

Phased approach we'd recommend

§4Discovery Call — Question List

Seven clusters, twenty-six questions. Order matters — the first cluster establishes whether the rest of the conversation makes sense; the last cluster (booking bundle) is our strategic suggestion to surface, not Brian's confirmed scope.

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.

Optional 5th surface — booking capture page (if booking bundle is in play)

If the §3 booking-bundle recommendation lands with Brian, adding a 5th surface to the demo makes the data flow tangible:

• Branded booking capture page. Customer-side view of what scanning a QR code in Marco's barbershop window leads to — a clean, branded "book your next cut with Marco's Cuts & Style" page that captures contact + service into CBP's system. Shows the V2 product in customer-facing form, makes the Trojan-horse mechanic visceral instead of abstract. Adds maybe a half-day to the demo build.

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