Multi-Tenant Platform for AI Video Production Agency

An AI video production agency (client identity withheld; built under contract via DevBrother) operated through a patchwork of tools: artist applications came in through Slack and forms, project intake from clients arrived as free-text emails or DMs, hiring decisions were tracked in spreadsheets, project work happened in unsynced messaging threads, no single source of truth for who was working on what.

The agency's bottleneck was operational throughput, not creative work. With multiple studio directors hiring in parallel and clients requesting custom video work daily, the team needed:

• One pipeline for artist hiring (apply → test → review → accept) with no overlap between studio directors competing for the same candidate
• Structured order intake that converted client free-text into actionable project briefs
• A project / task system where artist, reviewer, studio director, and client could all see status
• Per-user notification preferences and an audit trail of who did what

I joined as the sole engineer to build this from scratch.

A multi-tenant SaaS platform with the following surfaces:

Hiring / Talent acquisition

• Public artist application funnel with two paths: video test or portfolio submission
• AI test-assignment matcher (Google Gemini ranks open briefs against candidate skills)
• Pipeline review UI for studio directors and evaluators (1-5 rubric scoring)
• Accept flow: into a specific studio, or into a shared distribution pool
• Public artist profiles (no-auth URL, shareable in Slack)

Studios and projects

• Multi-tenant studio model with per-studio data scoping
• Projects with many-to-many client relationships
• Task kanban (To Do → Rough Cut → Fine Cut → Final Cut → Approved) with drag-and-drop
• Task health indicators (deadline tracking, block/unblock states)
• Per-task artist assignment, fee tracking, paid flag, artist payouts

Communication

• Per-project chat sidebar (staff ↔ client)
• Studio-wide chat channels, DMs, threads, @-mentions
• Edit/delete with 10-minute window
• Real-time via Supabase broadcast, fallback polling
• Task comments with rich editor and mention picker

Order intake

• Public AI-chatbot funnel (Gemini) that parses free-text client requests into structured orders
• Studio director accepts an order → platform auto-creates project, task, and client account

Notifications

• In-app Activity Center (32 audit event types)
• Email notifications via Brevo (25 transactional templates)
• Push notifications via Expo (mobile app integration)
• Per-user preferences, mute, HMAC unsubscribe tokens
• Cron-based deadline reminders

Customer success & admin

• Customer Health tab with weekly check-ins, health score 1-5, traffic-light status by days-since-contact
• Team management with multi-role assignment
• Audit log feed
• Feedback inbox with kanban
• Test assignment library

The role and permission model is capability-based with per-studio scoping. A user can hold multiple roles simultaneously — e.g., studio director of Studio A and artist in Studio B — with an "Acting As" switcher in the header. Studio directors see candidates and projects scoped to their studio; platform owner bypasses all scope checks.

Revenue (April 2026, first full month of revenue):

Positive unit economics confirmed in the first month of revenue. The platform went from MVP to operational revenue in 7 weeks of solo build.

Engineering throughput: 181 commits across the 7-week build period. Auto-deploy to production on every push to main. Test infrastructure included Vitest for unit tests, Playwright for E2E, with a parallel test schema in Supabase for isolated runs.

A 7-week build is a different category of project from a 7-month build.

The role/permission system warrants its own note. Roles live in users.role: platform_owner, studio_director, studio_manager, artist, client. An artist can additionally be is_evaluator=true. A user can hold multiple capabilities simultaneously — for example a studio director in Studio A who is also an artist in Studio B — and switch context via an "Acting As" toggle. Permissions are derived: a studio director sees pipeline candidates only for studios where they're director; a studio manager sees projects only for studios they're in.

• The "Acting As" pattern was the elegant solution to a problem that almost broke the role model. The agency's reality was that one person could be both an artist and a studio manager. With strict role-based access control (artists see X, managers see X + Y, directors see X + Y + Z across studios), this collapses immediately. Two accounts per person was a non-starter — duplicate identities, broken audit trails, user confusion. The fix was a capability-based permission model with an "Acting As" header switcher that lets a single account hold multiple capabilities and toggle context. Once that was in place, the strict tiered access (artist sees their work; manager sees their studio's artists + projects; director sees multiple studios + their own module) fell out cleanly. UX-wise it's a small switcher; architecturally it's the keystone of the whole system.
• AI integrations cost ~5% of build time and unlock ~30% of value. Gemini ranks test assignments and parses order intake. Both could have been form-based UIs requiring manual work. Both ended up as automated workflows that reduced studio director overhead by an order of magnitude. The integration code is small; the leverage is large.
• A 7-week build is a different category of project from a 7-month build. Decisions that would normally need careful weighing — choosing inline styles over Tailwind, JSON cookie sessions over JWT, Supabase broadcasts over a dedicated message queue — were made in minutes by picking the option that was simplest to ship. Some of those decisions will need revisiting at scale. Most of them won't.
• Strategic alignment with the client's product roadmap was the lesson I learned the hard way. This is honest: the agency has been developing its own internal platform in parallel, with overlapping ambitions in project management and operations. Their stack is different from mine — different framework, different database, different conventions. By the time this surfaced, my platform was already a 7-week investment with 181 commits, and the code couldn't be ported into theirs. The mistake was a planning one I'd recognize as a rookie product move: I didn't ask, on day one, what is the long-term plan for the system this will eventually integrate with? I optimized for shipping fast and proving the model, which I did — but the integration story is now strained. The takeaway I'm carrying forward: with internal-client builds, the first design conversation is about exit and integration paths, not feature scope.

The platform is in production and continues to handle real operations at the agency. Active backlog items: Stripe billing (currently on a feature branch, not yet on main), time-tracking (designed but not built), a reports / analytics dashboard (Activity Log and earnings tab exist; a dedicated reporting UI does not), per-studio Slack integrations (currently only one global webhook). A near-term architectural constraint to resolve is Vercel Hobby's 12-function limit — already at the ceiling, so the next iteration needs endpoint consolidation. Strategic question outstanding: given the integration limitations described above, whether the platform's long-term home is this client or whether the codebase becomes a reusable artifact for other agencies with similar operational patterns.