Skip to content

CreatorTrack , Creator-Platform Vision, Strategy & Build Plan

URL: https://mkdocs.justinsforge.com/memory/plans/creator-suite-vision-strategy-2026-06-17/

What CreatorTrack is (positioning, Justin's framing). CreatorTrack is a productivity app for content creators: all the workspace and project-management tools of Notion, mixed with custom content-creator apps , media management, agency work, email management, CRM, AI workflows, expenses and business accounting , all connected with AI so they work together as one system.

Tagline: CreatorTrack: Track Your Content Business.

Official product name (decided 2026-06-17): CreatorTrack.ai, handle @CreatorTrackAI (YouTube/TikTok/IG/X). Primary domain .ai ("AI" suffix unifies domain + social); .com is $27k, skip it, optionally grab cheap defensive domains later. "Track" is chosen for its full polysemy (path, course, route, system, follow, monitor, log, keep-track-of), which describes the whole creator OS, not just analytics; the VidCon "Creator Track" association reinforces native-to-the-space positioning. Trademark: descriptive but registrable; file a ~$250 USPTO mark later once the name is proven and money is going behind it, not now. CreatorTrack is now the name everywhere, internal AND external; "The Suite" and "Workspace" are retired as the product name (this doc keeps its old filename for stability but the product is CreatorTrack). IMPORTANT boundary: "workspace" survives ONLY as the internal multi-tenant DATA term (workspaceId, the RLS tenant container, the WorkspaceShell chrome component), exactly as Notion/Slack/Linear use it; CreatorTrack the product CONTAINS a workspace. Do not rename the data-layer "workspace" or the workspaceId column. Dev environment: dev.creatortrack.ai (Cloudflare tunnel to the :3060 dev server, behind CF Access, Justin-email-only); apex creatortrack.ai reserved for the future next build prod deploy. Repo dir forge-suite + tmux session names rebrand to CreatorTrack at a clean moment (not mid-build; dev server + workers run off those paths).

Build philosophy + tech stack (canon, 2026-06-18)

Build order (how we work). 1) Components first: every reusable UI building block is built once in a shared kit (components/ui, driven by app/theme.css tokens, previewed at /kit) so it is reused across the entire suite of tools; revise a token once and every tool re-themes. 2) Foundation next: build Notion-class tooling , the page/workspace framework (pages, blocks, and the database/collection engine with table/board/gallery/list/calendar views) , as the platform everything sits on. 3) Apps on top: build apps (finance, clips, creator CRM, habits, content calendar, analytics) that plug into that page framework; most are just configuration of the database engine (a schema + a view), a few are custom React modules. 4) Iterate back-and-forth: we move repeatedly across the three layers (kit <-> framework <-> app), hardening each aspect until its features actually work end-to-end, rather than finishing any one layer in isolation.

Tech stack. CreatorTrack is a single Next.js 16 application (App Router, React 19, TypeScript) served from the Console dev VM and previewed at dev.creatortrack.ai behind a Cloudflare Tunnel + Cloudflare Access (email OTP, Justin-only for now; graduates to Auth.js Google sign-in later, since the schema is already user-keyed). The data layer is a self-hosted PostgreSQL 17 instance , the core database (formerly "lifeos") , in LXC CT 109 (forge-data) on the Finn Proxmox host, with pgvector for embeddings/semantic search and Redis for cache/queues. Multi-tenancy is enforced in the database via Row-Level Security (RLS): every read and write runs inside a transaction stamped with the signed-in user through asUser(), so a user only ever sees their own rows. Drizzle ORM is the typed query client over that database, while Python migrations own all DDL (TypeScript never issues schema changes). The write path is uniform everywhere: client -> Next route handler -> mutation helper (lib/mutations.ts) -> asUser/RLS -> Postgres. Styling is one design-token sheet (app/theme.css) feeding a hand-built component kit (components/ui) plus the living /kit gallery, with no CSS framework. The data model is "everything is a node": pages, databases, and database rows all live in one app.nodes tree, and collections (databases) are defined by data (properties + views), which is exactly what lets new apps be configuration on the shared engine instead of new code. Media bytes (clips) live on NVMe, never in the database. Hosting is fully self-hosted today (Finn + Console); productization later adds managed Postgres + a Vercel/Fly deploy + Stripe.

Date: 2026-06-17. Author: [Claude Code], with Justin. This is the verbose anchor doc capturing the full strategic conversation (the back-and-forth, the decisions, the honest process correction, and the build plan) so we stop re-deriving it. Read with: - CreatorTrack workspace React rebuild plan: memory/plans/suite-workspace-react-rebuild-2026-06-17.md - Clip library: memory/handoffs/clip-library-findings-2026-06-17.md + memory/plans/gus-clip-library-mam-2026-06-15.md - UI kit + measured Notion values: memory/general/reference_suite_ui_kit.md - Clean-slate rule: feedback_suite_clean_slate_rebuild

0. TL;DR

We are building CreatorTrack: one React (Next.js) app where a Notion-style workspace is the home and creator-specific apps (clips/video library, creator CRM/email, analytics) are modules that live inside it, all on one multi-tenant Postgres (RLS) with AI woven through. Justin replaces Notion as his daily driver (so he needs real Notion-parity features for himself) AND this is the seed of a product for content creators (YouTube/ TikTok/IG full-timers). The unique, sellable wedge is the creator apps + the ability to build apps fast (and eventually let others build apps), not the Notion clone itself. Build order (Justin's explicit call): the next ≈4-5 days build the FOUNDATION (Notion- parity workspace + UI kit + building blocks/database engine) FIRST; THEN the clips app is built on top so Michael can search Gus footage and edit a long-form July-4 video (he needs ≥4 days to edit). Only the footage pull runs in parallel now (pure data). See §11.

1. The vision (birds-eye / dreaming)

  • Justin is learning data management, web apps, UI, design all at once and pushing into things he doesn't fully understand yet; that causes real mistakes (e.g. we built the workspace in Flask for days before realizing it was the wrong framework). He wants to spend time + money + TOKENS wisely. This work costs money, doesn't make money yet.
  • The honest test he posed: if we spend weeks building tools no better than Notion, what is the point? Building only for him + his brother, maybe not worth it on its own.
  • The bigger idea (the reason it IS worth it): a unique product for content creators. An all-in-one creator OS: a Notion-class workspace PLUS pluggable creator apps , a Frame.io-style video/clip management system, email + a creator CRM (linkable to a manager), VidIQ-style analytics, etc. , with the API/data flowing through the user's whole account into their own AI (Anthropic, or a self-hosted open model, or reselling Anthropic tokens). Creators use many tools; the bet is to unify them in one place. And to make those apps something people can create (a platform).
  • Scale question: can this support hundreds of users in ~a year (try with his brother, then a few creators, then more)? See §3 (yes, architecturally; productization is the gap).

2. The strategic reframe (what's commodity vs what's the wedge)

  • The Notion clone is the commodity layer. Notion exists and is better at being Notion. Perfecting a pixel-clone for just Justin + Michael is NOT worth weeks. BUT , correction Justin made , he is leaving Notion because it lacks the customization/range he needs (projects, tasks, habits, CRM, creator stuff, email), so he DOES need close-to-parity functional Notion features for his own daily use. Resolution: build the real Notion features he uses; don't burn weeks pixel-chasing perfection beyond what he needs.
  • The wedge is the creator-app layer + speed of building apps. Nobody bundles creator-specific apps into one workspace with the user's data + their own AI. Notion/ Monday/Linear are general; VidIQ/Frame.io are point tools; none unify for creators.

3. Will it scale to hundreds of users? (productization)

  • Architecturally yes. Postgres + Row-Level-Security + Next.js IS the multi-tenant SaaS pattern (one DB, per-user rows, RLS isolation; scales to thousands). We are on the right base this time (unlike Flask).
  • The gap is the productization layer, and ~60-70% of it is easy/standard:
  • Auth / accounts: Auth.js (NextAuth) gives "Sign in with Google" + sessions in an afternoon. RLS is ALREADY keyed on user_id, so real auth just replaces the current Cloudflare-Access-header trick , the isolation model already assumes a real user id.
  • Billing: add later via Stripe Checkout + webhooks; don't build now, just don't block it (we aren't). No charging at launch is fine.
  • Cloud hosting: a clean migration when needed , managed Postgres (Neon/Supabase/RDS)
    • deploy Next to Vercel/Fly. Home Proxmox box is fine for Justin + Michael + a few creators; hundreds of paying strangers on home hardware is a liability, so move then.
  • So: prove it on our metal with Michael + a few creators now; the jump to "hundreds" is a hosting/auth/billing migration (≈1-2 weeks of ops), NOT a rebuild.

4. The platform thesis , "apps as building blocks"

The key architectural insight (how Notion/Coda/Airtable actually work): - Most "apps" are not custom code , they are a database with a specific schema + view. - Tasks = a DB with Status/Assignee/Due + a Board view. - Habits = a DB with checkbox-per-day + a calendar/grid view. - CRM = a DB of contacts with Stage/Owner + relations to deals. - Content calendar = a DB of posts with Date/Platform/Status + a calendar view. - So build one strong collection/database engine , properties (text/select/status/date/ number/relation/formula), views (table/board/calendar/gallery/list), filters/sorts, templates , and tasks/habits/CRM/projects/content-calendar become configurations of that engine, NOT separate apps to code. This is the commoditization: spin up a new app in minutes (schema + view + template). The SAME engine delivers Justin's own Notion parity. - Genuinely custom apps (clips/video = player + ML; analytics = API pulls + charts) stay as hand-built React modules using the UI kit + data layer. - Platform = [database engine for CRUD apps] + [custom React modules for special apps] + [the UI kit] + [the node/registry that hosts them all]. - "Others build apps too" path: templates first (share a schema+view config), then an app SDK later (define a schema + a React view against the kit + data layer, register a node type) , exactly how Notion has an API, Coda has Packs, Shopify/Whop have app stores. Our node-type -> renderer registry + RLS data layer is already the right shape for this.

5. Are we using the right tools? (general)

  • Yes. Notion, Linear, Monday, HubSpot, VidIQ, Rocket Money, Meta Business, Whop are ALL React/TypeScript front ends + a backend + Postgres-or-similar + multi-tenant. We are on Next.js + React + TS + Postgres + RLS , the same industry-standard stack. Study Linear (it feels instant via a local-first sync engine + optimistic UI); that's execution depth, not a different tool. Our differentiator will be depth + the creator-app bundle, not stack.

6. Legality of cloning Notion's look/colors

  • Colors and look-and-feel are not copyrightable/protectable. We can use the same dark grays, layout, and UX (open Notion clones like AppFlowy do exactly this). What we must NOT do: use Notion's name/logo/trademarks, copy their code, or use fonts/assets they license. A Notion-style palette + the system font stack = fine, low risk. (Not legal advice; this is well-settled , UIs get cloned constantly.)

7. UI kit + seeing/testing/editing components on the web

  • Justin's pain: "I can't see the code, so I don't get how to make these building blocks permanent/consistent; wish I had a look into the back end or mockups of how elements look."
  • Fix: every reusable element (Sidebar, NavItem, Menu, Dropdown, Card, Button, Input) lives ONCE in components/ui (built on the design tokens in app/theme.css), used everywhere.
  • Plus a living /kit gallery page that VISUALLY shows every block + variants, with live controls (tweak props/tokens and watch it re-render; editable theme so a color change cascades). That IS the "mockups" he wants + the retheme knob + the test surface , all on the web, no code-reading. (Storybook is the off-the-shelf alternative; custom /kit is more accessible for Justin.) Build a component once -> drop it in the gallery -> permanent, consistent, visible.

8. Honest process correction (why earlier attempts felt thin)

  • What works: faithful PORT , read the actual source (the Flask forge_*_ui_*.py or the live app), measure the live UI (getComputedStyle off Justin's Flask app AND real Notion), reproduce it completely, verify side-by-side. Finance reached real parity (numbers to the dollar) BECAUSE I did this per area.
  • What fails: sketching a thin "MVP / next slice" from memory/screenshots. The workspace shell came out ~20% because I freehanded instead of porting the finished Flask features (page-row hover + +/… menus, toolbar drag-resize, how blocks really behave, the database views) , all of which already exist in Justin's 500KB of Flask code.
  • Capability truth: I cannot intuit/invent Notion's or Justin's app's full depth from a screenshot, and I can't reproduce the 2 days of decisions by vibes. I DON'T need to , it's in the Flask code + logs + the running apps. My output is bimodal: deep where I port rigorously, shallow where I sketch. Rule going forward: faithful, feature-complete port per surface, no "rest is later." It's slower but it actually reaches parity.
  • On Gemini's advice (data-first prompting): sound general principle, but it MISDIAGNOSED our case , our data is already real (schema + RLS built first; React reads/writes real Postgres via asUser; create/edit verified end-to-end), NOT mock data. Our gap is feature depth, not data flow. We are self-hosted on Proxmox (CT 109 on Finn/MS-01), not Supabase, by choice.

9. What already exists (don't rebuild)

  • core database (CT 109, Finn; physical db still named lifeos until the scheduled rename): Postgres 17 + pgvector + Redis; multi-tenant RLS; schemas core (users/workspaces/login/RLS) + app (nodes/blocks/collections/registry) + finance + domains.
  • CreatorTrack (forge-suite repo, Next 16/React/TS): Workspace shell (collapsible Notion sidebar, matched to real Notion), page view (cover/icon/32-700 title) + editable block editor, database table view, nested sidebar tree, workspace asset serving, the canonical core write path (client -> route -> mutation -> asUser/RLS -> Postgres, verified), the finance module (mostly built), UI-kit tokens + seed primitives, /kit preview.
  • Clip library (planned + validated): suite media module; Premiere handoff via FCP7 .xml is VALIDATED on Justin's Windows Premiere (forge_premiere_xml_builder); footage = 5-10k iCloud videos via icloudpd (no Mac); CLIP/Whisper tagging on Vector's RTX 5070 (NOT CT 109); bytes on NVMe, never in DB.

10. Practical plan , the July-4 clips deadline (≈4-5 days build, then ≥4 to edit)

Goal: Michael searches Gus footage, selects clips, sends them to Premiere, edits a long-form video. Data-first critical path: 1. Footage pull (long-pole, start ASAP, parallel): icloudpd -> NVMe. BLOCKER: Michael's Apple ID app-specific password in ~/.forge-secrets/icloud-michael.env (Justin adds it; I never see it). The copy itself takes time. 2. media schema MVP in the core database (RLS, gus-the-bass workspace): clips table (path, thumbnail, date, duration, caption, tags, pgvector embedding; bytes stay on NVMe). Designed to GROW into Frame.io (review/comments/versions/shares reserved, not built now). Justin will carve the schema. + Python ingest worker (scan files -> rows + FFmpeg thumbnails/proxy). 3. Clips module UI (clips node type -> React view): gallery, date/text filter+search, in-browser player, multi-select. Good-enough workspace shell to host it. 4. Send-to-Premiere (.xml, already built/validated): select clips -> emit bin .xml. 5. Fast caption/tag review mode (iPhone PWA): big preview, tap-heart, type one line, swipe. 6. AI semantic search (CLIP) , the wow feature ("Gus eating minnows") but cuttable to v2 if the clock is tight; date + manual tags + thumbnails get Michael editing on time. Honest scope: footage-on-server + catalog + browse/search + send-to-Premiere is achievable in the window and unblocks editing; CLIP search lands after.

11. Priority stack , FOUNDATION FIRST (Justin's explicit order)

The next 4-5 days = build the FOUNDATION (Notion-parity workspace + UI kit + building blocks/database engine) BEFORE building the clips tool. The clips app is built ON TOP of the foundation, not bolted onto a thin shell. Only the footage pull runs in parallel now (pure data, no UI, the long-pole). Build a real PORT (read the Flask source + measure live Notion), not a sketch.

Phase A , Foundation (the 4-5 day sprint), in order: 1. UI kit + building blocks , every reusable element (Sidebar, NavItem, Menu, Dropdown, Card, Button, Input, Modal, ContextMenu) as named components/ui on the tokens, + the /kit gallery (see/test/edit on the web). These are the bricks every app reuses. 2. Database/collection engine , the biggest building block: properties (text/select/ status/date/number/relation/formula), views (table/board/calendar/gallery/list), filters/ sorts, add-row/edit-cell, templates. Tasks/habits/CRM/projects fall out as CONFIGS. This is BOTH Justin's Notion-parity need AND the platform core. 3. Notion-parity workspace , faithful port of the page editor depth (slash menu, marks, block types, drag), the sidebar (hover + + add-child + … menu), the topbar/breadcrumb, icon/cover picker. Real port from forge_workspace_ui_*.py + measured off live Notion.

Parallel now (pure data, no foundation dependency): kick off the icloudpd footage pull (needs Michael's Apple ID app password) so 5-10k Gus videos copy to NVMe while we build.

Phase B , AFTER the foundation is solid: the clips app (media schema MVP + ingest + clips module UI + Send-to-Premiere + caption mode + CLIP search v2), built on the engine + kit.

Later (productizing): Auth.js Google accounts, Stripe, cloud migration , each when warranted.

12. Open blockers / from Justin

  • Apple ID app-specific password (Michael) -> ~/.forge-secrets/icloud-michael.env to start the footage pull.
  • Confirm the build order: start media schema MVP now (data-first) while footage copies.

[Claude Code]