imedia8 × StudentBridge · Platform alignment
Video Library platform
From one client build to many clients
Team alignment before build·October 2026
What the Suffolk build contains
One HTML file, 3,437 lines, everything inline
22
videos
title, category, tags, quote, poster, MP4
57
app methods
grids, player, PiP, search, modals, sidebar, chat
372
brand hex codes
navy and gold typed into Tailwind classes
86
“Suffolk” in copy
plus 69 “Boston”, 13 “Rams”
Hero video Make It Yours 4 video sections Category modal Player + PiP Search StudentHUB Tour progress FAQ · Key dates Chat assistant Mobile bottom nav
Shared shell vs. tenant configuration
Built once · code
The renderer
  • Layout, responsive rules, bottom nav
  • Video player, PiP, transcript
  • Search, filtering, category modal
  • StudentHUB drawer and progress logic
  • Saved / watched / continue state
  • Make It Yours behaviour (drag, minimise)
  • Analytics events
Per client · data
The tenant file
  • Brand: colours, fonts, logo
  • Copy: hero, section titles, CTA labels
  • Video catalogue and categories
  • Interest chips
  • Which sections show, in what order
  • Tour stops, FAQ, key dates
  • Chat assistant persona and knowledge
  • CTA destinations and feature flags
The tenant data contract
Ten top-level keys. Admin UI writes it, renderer reads it, nothing else crosses the line.
brand
primary, secondary, surface, font family, logo URL, favicon
copy
hero headline + body, section titles + subtitles, banner, newsletter, footer
videos[]
id, title, category, tags, duration, poster, src, transcript, quote, label
categories[]
name, blurb, cover image, interest chip it maps to
interests[]
label, icon, matching tags
sections[]
ordered list: type, title, source rule (recommended, continue, most-viewed, categories)
tour[]
ordered stops, each pointing at a video id
hub
FAQ items, key dates, quick-action labels
ctas
apply, visit, request-info URLs; chat persona + endpoint
features
studentHub, pip, makeItYours, chat, signIn, newsletter
A tenant file, in practice
Suffolk, expressed as data. Change the brand block and the same renderer produces a different university.
  • →Colours become CSS variables, not class names
  • →Videos reference categories by key
  • →Tour stops reference videos by id
  • →Sections are an ordered list, so clients can drop or reorder
{
  "tenant": "suffolk",
  "brand": {
    "primary": "#13284c", "accent": "#f0b323",
    "surface": "#203962", "font": "Montserrat",
    "logo": "cdn/suffolk/logo-reversed.svg"
  },
  "copy": { "hero": { "headline": "Boston is our campus.",
                      "emphasis": "Make it yours." } },
  "interests": ["Business", "Arts & Sci", "Boston Life",
                "Transfers", "Graduate", "Athletics"],
  "sections": [
    { "type": "recommended", "title": "Recommended For You" },
    { "type": "continue",    "title": "Continue Exploring" },
    { "type": "popular",     "title": "Most Viewed Videos" },
    { "type": "categories",  "title": "Explore more" }
  ],
  "videos": [ { "id": "dil", "title": "A Day in the Life…",
                "category": "student-life", "duration": 140,
                "src": "cdn/…/3_1_DIL_v3.mp4" } ],
  "tour": ["ridgeway", "sargent", "sawyer", "samia"],
  "ctas": { "apply": "https://…", "visit": "https://…" },
  "features": { "studentHub": true, "pip": true,
                "signIn": "optional", "chat": true }
}
How a client page is assembled
Domain selects the tenant; one renderer serves every client
01
Admin UI
Client team edits brand, copy, catalogue, flags. Preview before publish.
→
02
Tenant store
Versioned JSON per tenant plus media on CDN. Publish = new version.
→
03
Renderer
The Suffolk front-end, made generic. Reads tenant JSON, applies brand as CSS variables.
→
04
Client page
videos.client.edu, or embedded in the client's site. Same build, their brand.
Visitor state (saved, watched, interests) lives in the browser until sign-in, then syncs Analytics tagged with tenant id at the renderer
Visitor accounts: optional sign-in
StudentHUB has two states. Both must work fully; today's build fakes the second.
Anonymous
Default for every visitor
  • Interests, saved, watched, tour progress kept in the browser
  • Continue watching works across the session
  • Apply / Visit / Request Info go straight to client URLs
  • Prompt to sign in appears in the HUB, never blocks
Signed in
Email or client SSO, decided per tenant
  • Browser state migrates to the account on first sign-in
  • Progress follows the visitor across devices
  • Profile card, name, saved count become real
  • Lead data available to the client's admissions team
What has to be unpicked first
Four mechanical refactors on the Suffolk file, each a self-contained change
1
Colours → CSS variables
372 hard-coded hex values inside Tailwind class names become var(--brand-accent)
2
Copy → template slots
Every headline, subtitle, button label and footer line reads from copy.*
3
videoData → fetched catalogue
The inline array, Tailwind label colours and suffolk- ids move out to the tenant file
4
Static sections → rendered from list
Hero, four rows, category grid, CTA cards, banner and footer become section types driven by sections[]
Build sequence
Prove the renderer with a second tenant before building the editor
PHASE 1
Extract
Pull Suffolk's brand, copy and catalogue into a tenant JSON. Lock the schema.
PHASE 2
Generalise
Renderer reads the JSON. Suffolk must look identical to today.
PHASE 3
Second tenant
A real or demo client on the same renderer. Whatever breaks here is a schema gap.
PHASE 4
Admin UI
Editor over the now-stable schema, with preview and publish. Then sign-in.
Decisions before Olaf starts
01Hosting model: our subdomain per client, client's own domain, or embed in their site
02Where video lives: StudentBridge CDN only, or client-supplied URLs too
03Sign-in provider: our accounts, client SSO, or both
04Chat assistant: scripted per tenant, or an LLM over the tenant's catalogue and FAQ
05How much layout a client may change: sections on/off and order only, or templates too
06Second tenant for Phase 3: which client, and when