Design brief — marketing surfaces: tenant home page & editor recruitment

For: Claude Design (or any designer). Companion to DESIGN-BRIEF.md (the system) and the implemented token/component library — these two pages must be built FROM that system, not beside it. Where this brief conflicts with the code or the schema, the code wins — flag, don't guess.

Two pages, two audiences, one hard architectural rule:

Demand is tenant-scoped; supply is platform-scoped (ARCHITECTURE §2). Never blend the two voices on one page.

1. / — the tenant home page

Current state

A Phase-1 debug stub (tenant slug, sign-in link, build-plan note). Replace entirely. It is the first thing a prospective client sees when the tenant shares their link — today it undersells everything behind it.

Audience & jobs-to-be-done

1. First-time visitor (charter manager, owner's assistant — on a phone, sent here by word of mouth): "Is this premium? Is this effortless? What does it cost? How do I start?" — convert to Start an order or at least scroll the packages.
2. Returning client: get to Sign in / My jobs in one glance, without wading through marketing. If already signed in, the hero CTA becomes "My jobs" (the page already knows — keep that logic).

The concept being sold (message architecture, in order)

1. Hero — the promise. One sentence, outcome-first, vertical-agnostic engine copy with tenant-config override: default slot: "Professional edits of your footage — delivered in days, not weeks." + subline: "Send us what you shot. We turn it into scroll-stopping video." CTA primary: Start an order; secondary: Sign in. (Copy lives in a tenant-config slot, e.g. theme.tagline/theme.subline, with these engine defaults — never hardcode yacht copy; Wakecut sets its own via config.)
2. How it works — 3 steps, calm and concrete. This is the differentiator; design it as the centerpiece:
   • 1 · Brief & book — pick a package, tell us what you want, pay securely (authorized, not charged until you approve).
   • 2 · Send footage, any way you like — drag-and-drop multi-GB uploads, connect Dropbox/Drive/Photos, or just paste a WeTransfer link. "If we can't fetch it automatically, our team will." (Real capability — say it.)
   • 3 · Review & approve — watch a preview, request changes within your package's revisions, approve — you're only charged then, and your files arrive.
3. Packages — live from the DB. Render the tenant's actual catalogue (packages: name, description, price in the tenant's currency, rush_available badge, revision_limit as "N revisions included"). Reuse the package-card component from /order (PAGE-SPECS 2b) — same card, marketing context. NO hardcoded prices anywhere; the seed's placeholder prices are what render until the operator replaces them.
4. Trust strip. Short, factual, no badges-for-badges'-sake: payment held until approval (Stripe) · your footage stays private (EU storage, GDPR) · watermarked previews until you approve · a real human QC's every edit.
5. Closing CTA repeating Start an order.

Element inventory & data bindings

• Tenant name/logo: tenants.name, theme.logo_url (text fallback) — reuse TenantHeader.
• Accent/primary/font: runtime CSS vars (already wired via src/lib/theme.ts).
• Hero copy: theme.tagline / theme.subline slots, engine defaults above.
• Packages: same query as /order (active, tenant-scoped, price via billing_config.currency); rush badge only when rush_available.
• Auth-aware header/CTA: signed-in → "My jobs" (/jobs); anonymous → "Start an order" (/order — which redirects to /login first; that flow is acceptable, magic-link sign-in doubles as sign-up).
• Signed-in banner variant: compact "Welcome back, {profile.name} — My jobs →".

States

anonymous · signed-in (client) · signed-in (admin/editor: keep the marketing page but swap CTA to their surface — /ops, /workspace) · tenant with zero active packages (hide section, keep CTAs) · unresolved tenant (neutral engine fallback page: name "Redpoint Engine", no packages).

Notes

• Mobile-first 360px; the hero must not push "how it works" below two viewport heights on a phone.
• Voice: DESIGN-BRIEF §4/§6 — calm, competent, zero jargon ("footage", not "assets"; "approve", not "sign off deliverables").
• The engine is currently unlisted (robots disallow-all). Keep noindex for the demo; the brief's SEO metadata (title/description/og tags from tenant config) should be DESIGNED now and flipped on when the operator de-lists. That is an operator decision, not a design one.

Acceptance criteria

1. A first-time visitor on a phone understands offer, process, and price range within one scroll.
2. Zero yacht-specific (or any vertical) copy in code — all brand voice from tenant config slots with generic engine defaults.
3. Package cards render live DB data; empty catalogue degrades gracefully.
4. Signed-in clients reach /jobs in one tap; anonymous reach /login-gated /order in one tap.
5. Uses only existing tokens/components + this page's new marketing sections; dark-mode not required (client surfaces are light).
6. e2e-testable hooks: hero CTA, package cards, auth-aware swap.

2. /editors — the recruitment page

Audience & job-to-be-done

Working freelance/staff video editors (NLE-proficient, portfolio in hand) who are tired of client acquisition, scope creep, and chasing invoices. Job: convince them to apply in under two minutes of reading.

The pitch (message architecture)

1. Hero. "Edit. We handle everything else." Subline: "Clients, briefs, uploads, revisions, invoicing, payouts — handled. You get footage in and a clear brief; you send a great edit back."
2. How it works for editors — the loop, honestly:
   • Jobs arrive assigned, with a structured brief and the footage already collected — no discovery calls, no chasing files.
   • You work under a pseudonym — clients never contact you directly; QC and client communication are handled by the platform.
   • A workload cap you control — you're never assigned more concurrent jobs than you accept (real mechanism: max_concurrent_jobs + availability toggle).
   • Paid per job via Stripe — payout share shown on every job before you start; no invoicing. (Payout split is an operator placeholder — [EDITOR PAYOUT SPLIT] — the design shows a slot like "you keep {X}% of every package", never an invented number.)
   • Clear feedback loops: QC notes and client revision requests arrive as written notes on the job — bounded by the package's revision cap, so scope can't creep.
3. What we look for. Honest bar-setting: portfolio-grade short-form work; turnaround reliability; the vetting process stated plainly — apply → short paid test edit → approved into the pool (mirrors vetting_status: applied → test_assigned → approved).
4. Application form (interest capture). Minimal: name, email, portfolio/reel URL, primary NLE/tools, note (optional). Submitting creates an application record — design the form + a calm success state ("We review every application and reply within a few days."). Build note for the implementation packet, not the designer: whether this writes an editor_profiles(applied) row + profile or lands in a simpler inbox is an engineering decision; Phase 10 owns full self-serve onboarding. Design the form as if it works; keep fields to exactly these five.

Branding & placement

• Engine-neutral: Redpoint platform voice, not tenant-themed — no tenant accent, no tenant name. Visually: the light engine palette with restrained dark-surface accents echoing the editor's actual workspace (a subtle "this is the tool you'll live in" preview — e.g. a framed workspace screenshot or stylized job-card mock in engine-dark).
• Route /editors exists on every tenant host (host-agnostic content). Footer of / gets a quiet "Editors — work with us" link; nothing louder (don't recruit on the client's buying journey).
• Same unlisted/noindex posture as above until the operator de-lists.

States

anonymous (default) · signed-in editor (swap CTA to "Your workspace →") · form: idle / submitting / success / error.

Acceptance criteria

1. An editor understands the working model (assigned jobs, pseudonymity, cap, per-job payout, vetting) without leaving the page.
2. No invented numbers: payout %, rates, and turnarounds render from config slots/placeholders only.
3. Application form captures exactly: name, email, portfolio URL, tools, optional note — with accessible labels and a designed success state.
4. Zero tenant branding; must render identically on any tenant host.
5. Built from existing tokens/components; one new "feature list" and one "application form" section pattern maximum.

Shared constraints

• Implementation target unchanged: Next.js App Router + Tailwind + the existing src/components/ui/ library and token layers. New section patterns (hero, steps, trust strip, feature list, application form) should be designed as reusable components — Phase 8's second tenant gets the same home page for free via config.
• WCAG AA; mobile-first for /, responsive for /editors.
• No stock photography; if imagery is wanted, prefer abstract/product-real (UI fragments, chips, timeline motifs from the existing system).
• Out of scope: tenant marketing sites (separate apps, ARCHITECTURE §1), blog/SEO content programs, the full editor onboarding flow (Phase 10), pricing changes (operator placeholders stand).

Deliverables requested from Claude Design

1. / home page: mobile (360) + desktop (1280) layouts, all states in §1.
2. /editors: desktop + mobile layouts, all states in §2.
3. The new section patterns (hero, steps, trust strip, feature list, application form) as specs consistent with the shipped component library.
4. Microcopy for every slot as engine defaults (tenant overrides come from config) — same voice rules as DESIGN-BRIEF §4.
5. HTML/Tailwind-level output as before — it ports 1:1 into implementation packets.