Skip to content

Briefing: Creator/affiliate stack, tool-by-tool (Forge vs CreatorTrack, Justin vs Michael)

URL: https://mkdocs.justinsforge.com/memory/plans/creator-stack-tool-briefing-2026-07-08/

Date: 2026-07-08 Scope: Affiliate + creator-website buildout for JustinWieb and Gus the Bass. For each layer: the tool worth using, its API/backend, why we want it, where it lives (Forge infra vs CreatorTrack app vs rented SaaS), how Justin (dev/root) controls it, how Michael (non-technical co-manager of Gus) interacts.

Two organizing rules: 1. Own the front door + the data; rent the heavy backends + the network-effect stuff. (bio page, storefront, email forms, contact record = build; payments, delivery, community, course-hosting = rent.) 2. Placement follows who touches it. If Michael needs to change it, it must have a UI inside CreatorTrack (he already uses CT with workspace sharing + per-app permissions). If only Justin configures it, it lives in Forge (CLI/API/secrets) or the vendor dashboard.

Layer 1: Presentation (bio page, storefront, brand sites)

Tool: Build our own, inside CreatorTrack ("Links" module) + static publish to the real domains.

  • API/backend: CreatorTrack Postgres. New tables links.pages, links.blocks, links.products, links.clicks, links.captures. Public renderer serves gusthebass.com/links, /shop, justinwieb.com/links via Cloudflare routing to CT (or CF Pages pulling from the CT API).
  • Why: Linktree/Beacons hold their copy of your audience, un-scriptable, templated look. Owning it means custom design, your analytics, your email list, and Forge can read/write everything.
  • Lives: CreatorTrack app (editor) + Forge/Cloudflare (domain routing).
  • Justin controls: schema, renderer, domain/tunnel config, deploys via git push.
  • Michael uses: a CT app where he adds/reorders blocks (link, affiliate card, storefront section, email-capture) for the Gus workspace, drag-and-drop, hit publish. No code. Per-app permission scopes him to Gus.

Benchmark to steal from, not adopt: Framer (site design), Beacons (block types). Look, don't rent.

Tool: Dub.co (open-source, self-hostable or cloud).

  • API/backend: Full REST API + webhooks. Branded short domain (e.g. gus.link/rod), per-link click analytics, QR codes, UTM builder. Self-host on Forge or use their cloud.
  • Why: Every affiliate link becomes a trackable short link. Clicks flow to your spine. QR codes go on packaging / in videos. This is the measurement seam between content and page.
  • Lives: Forge (self-hosted container) OR Dub cloud; either way CT reads its API.
  • Justin controls: deploy/host, API keys, domain setup, webhook → CT ingestion.
  • Michael uses: nothing directly. When he adds an affiliate card in the CT Links editor, CT auto-creates the Dub short link behind the scenes. He just pastes the raw affiliate URL; the tracking is invisible to him.

Layer 3: Affiliate networks (UPSTREAM, required, boring)

Tools: Amazon Associates (+ Levanta), ShopMy or Howl/Narrativ, Impact / ShareASale / CJ.

  • API/backend: varies. Amazon PA-API (product data, rate-limited), Levanta + Impact have reporting APIs. These are the source of commission links + product data.
  • Why: The storefront has nothing to sell until you're enrolled in the programs. This is paperwork, not a build, and approvals take days.
  • Lives: external accounts (not Forge/CT). Product data pulled via API into links.products.
  • Justin controls: API credentials, the sync job that pulls product data into CT.
  • Michael uses: picks products in the CT editor from a synced catalog, or pastes an affiliate link and CT enriches it (image, title, price) via the network API.

Layer 4: Analytics

Tools: PostHog (cloud) + Affilimate + Dub (from Layer 2).

  • PostHog: product analytics, funnels, session events, feature flags, A/B. Full API + webhooks. Cloud, not self-host (self-host proven painful, CT114 was destroyed). Already the Forge standard.
  • Why: answers "bio tap → capture → click → convert" as a funnel, not just raw counts.
  • Affilimate: aggregates affiliate commissions across all networks into one dashboard + link-level revenue attribution. API-first.
  • Why: the only tool that answers "which rod actually made money," which plain clicks can't. This is the affiliate-revenue measurement layer.
  • Lives: rented SaaS, both API-reachable. CT surfaces a simplified view.
  • Justin controls: PostHog project keys, event schema, Affilimate connection to networks.
  • Michael uses: a read-only "Gus analytics" tab inside CT (top links, emails captured this week, top-earning products) built from PostHog/Affilimate/Dub APIs. He never logs into PostHog itself; CT shows him the 5 numbers that matter.

Layer 5: Email collection + sending

Tools: Mautic (owned, CT112) + Resend (delivery). NOT Listmonk (removed 2026-07-08).

  • API/backend: Mautic REST API (segments, contacts, campaigns); Resend API/SMTP under it (DKIM per brand domain). Both already running.
  • Why: you already own the whole stack, zero new rent. Bio-page capture → Mautic segment (per brand) + CT contact record. Resend delivers.
  • Lives: Forge (Mautic CT112 + Resend account).
  • Justin controls: Mautic infra, Resend keys, segment structure, the capture → Mautic API write.
  • Michael uses: two options depending on appetite: (a) log into Mautic's own UI to send a Gus newsletter (it's Mailchimp-like but clunky), or (b) a thin "send to Gus list" composer inside CT that calls the Mautic API. For a non-technical user, build (b) so he stays in CT. Captured emails just appear; he doesn't manage the plumbing.

Layer 6: CRM

Tools: already own three: CreatorTrack Sales/Personal CRM, ERPNext (CT104), Copper (markai).

  • API/backend: CT CRM = your schema; ERPNext = full REST + webhooks; Copper = API via markai :8102.
  • Why: don't add a fourth. Leads from the bio page route into CT's CRM. ERPNext is the commerce/finance spine if it gets transactional.
  • Lives: CreatorTrack (day-to-day CRM) + Forge (ERPNext).
  • Justin controls: routing rules, ERPNext, API wiring.
  • Michael uses: CT Sales CRM UI, scoped to Gus. Sees leads/contacts that came from the Gus bio page, can tag/note them. Familiar CT surface.

Layer 7: Community

Tool: Discord + a Forge bot. (Not Skool: rent Skool/Circle only for discovery, later.)

  • API/backend: Discord API + bot framework (first-class). Forge bot can post content, DM new members, gate channels by role, sync members → CT.
  • Why: audience already has Discord open, free, real-time, and Forge can genuinely automate it (unlike Skool). It's the destination the bio page funnels into.
  • Lives: Discord (rented room) + Forge (the bot).
  • Justin controls: the bot (member sync, auto-posting, role gating), server structure.
  • Michael uses: he's a moderator/admin in Discord like any human, posts and replies. No CT involvement needed. If we want member counts in CT, the bot writes them to the spine.

Layer 8: Course hosting + paywall (LATER, only when there's a paid thing)

Tool: Whop (marketplace + checkout + course host + Discord gating).

  • API/backend: API for products/members/access. Handles Stripe checkout, gates Discord roles by purchase, hosts the course library, has a discovery marketplace.
  • Why: gives the Skool bundle (course + paywall + community gate) while keeping Discord as the community. Don't build a course platform.
  • Lives: rented SaaS, API-reachable → CT/ERPNext for the money record.
  • Justin controls: Whop account, API, Discord-gate wiring, Stripe underneath.
  • Michael uses: Whop's own creator UI to add lessons / manage members, OR we surface sales in CT. Only relevant once Gus sells something.

Alternatives considered: Circle (community + course, better API than Skool, no discovery), Kajabi (all-in bundle, expensive, walled), Metafy (1:1 coaching marketplace, wrong shape, skip).

Layer 9: Payments (whenever money moves)

Tools: Stripe (digital / checkout) + Shopify (physical products, if any).

  • API/backend: Stripe = best-in-class API + stripe CLI. Shopify = Admin + Storefront API + Shopify CLI (already your pattern).
  • Why: never build payments (compliance/tax/fraud). Stripe for course/membership, Shopify if Gus ever sells physical goods with inventory.
  • Lives: rented, API-reachable.
  • Justin controls: keys, webhooks → ERPNext/CT for the ledger.
  • Michael uses: nothing, or a CT "sales" view. Payments are backend.

The control model in one line

  • Justin = root/API/infra. Owns schemas, deploys, secrets, bots, sync jobs, vendor config. Works from Forge CLI + vendor dashboards.
  • Michael = CreatorTrack UI only. Everything he touches is a CT app scoped to the Gus workspace by per-app permission: the Links editor, a simplified analytics tab, the CRM, and a thin email composer. He never sees Dub, PostHog, Mautic internals, or a terminal. The rule that makes this work: if Michael needs it, it gets a CT UI; otherwise it stays in Forge.

Build order (unchanged)

  1. gusthebass.com/links end to end (capture → Mautic + CT, click → Dub), live.
  2. Instrument (PostHog + Dub + Affilimate).
  3. Clone to justinwieb.com/links + storefront.
  4. Discord + Forge bot.
  5. Whop + Stripe when there's a paid product.

Parallel paperwork while #1 builds: enroll in the affiliate programs (Layer 3), they take days to approve.