Case study · AI product delivery and product operations
FastVideo — AI Video Product & Delivery System
A six-stage AI video workflow with the operating layer required to review, render, launch, and improve it.
Technical Project Manager · Product Operations Lead
- DeliveredDelivered product system · production-readiness work
- Sanitized reconstructionPublic case study
01 · At a glance
What this system enabled
- Business need
- A six-stage AI video workflow with the operating layer required to review, render, launch, and improve it.
- Nelcys’s role
- Technical Project Manager · Product Operations Lead
- What was delivered
- AI product delivery and product operations
- Core systems
- Next.js · Supabase · Remotion · ClickUp
Maturity and public status
- DeliveredDelivered product system · production-readiness work
- Sanitized reconstructionPublic case study
02 · Business need
What the business needed
FastVideo required more than feature delivery. The product needed one coherent path from creative input to reviewed, render-ready output, plus an operating model that connected product work to launch, GTM, customer handoff, and leadership visibility.
Nelcys structured that path, directed implementation priorities, validated system behavior, and built the surrounding delivery controls.
03 · What needed to change
The operating risks to resolve
FastVideo required more than feature delivery. The product needed one coherent path from creative input to reviewed, render-ready output, plus an operating model that connected product work to launch, GTM, customer handoff, and leadership visibility. Nelcys structured that path, directed implementation priorities, validated system behavior, and built the surrounding delivery controls.
A six-stage workflow had to preserve project state and user confidence across generation, review, and export.
Scene-aware routing, internal animation, worker behavior, and output logic introduced dependencies beyond the visible interface.
Product, go-to-market, onboarding, and support work needed shared readiness criteria and escalation paths.
AI-assisted implementation required architecture constraints, tests, and evidence rather than prompt-level acceptance.
04 · What I delivered
My role in the system
I owned the business outcome, operating logic, system boundaries, acceptance criteria, delivery direction, validation, and final acceptance. AI-assisted development and specialist collaboration supported implementation where the context required them.
- Translated the product vision into workflow, system, and release requirements.
- Directed architecture constraints across project state, scenes, review, rendering, and export.
- Defined reusable media, voice, and music library behavior across the project workflow.
- Defined readiness, acceptance, escalation, and product-to-market handoffs.
- Built the ClickUp operating model for development, daily priorities, SOPs, onboarding, and leadership visibility.
- Governed AI-assisted implementation through tests, production constraints, and evidence.
05 · How it works
How the system works
The product moves from script through voice, visuals, music, output, and export while maintaining scene and project state. A delivery operating layer turns technical progress into visible readiness, handoffs, onboarding, and escalation.
Selected system
Script → Voice → Visual → Music → Output → Export
Builds a project through distinct, reviewable AI-assisted stages.
Boundary: Each stage must preserve project and scene context rather than behave as an isolated generator.
Systems in context
- Next.js
- User-facing creation workflow and project-centric application layer
- Supabase
- Persistent project state, authentication, render-job state, and media storage
- Remotion
- Programmatic video composition and render preparation
- ClickUp
- Product delivery, release, onboarding, and escalation control
- Railway
- Configured host for the separate background render worker
- FFmpeg
- Final audio muxing, compression, and export reliability in the render path
- Vercel
- Next.js application deployment context
- GitHub
- Source, version history, implementation review, and technical handoff
- Claude Code
- AI-assisted implementation under human direction and review
- OpenAI Codex
- AI-assisted implementation, testing, and validation support
06 · How I think
The decisions behind the system
Tools change. The durable work is deciding what owns truth, what may move, what must stop, and what evidence is enough.
Model the full product pathTreat generation, review, rendering, and export as one connected delivery system.
- Why
- A convincing interface is not a successful product if the render path is unreliable or state is lost between stages.
Make scenes reviewablePreserve scene-aware routing and review points before output is finalized.
- Why
- Users need to inspect and correct the unit that will actually render.
Define completion through evidenceTie readiness to verified behavior, dependencies, and output rather than a ticket status alone.
- Why
- AI and media pipelines can appear complete while downstream work is still broken.
Connect product and go-to-market workUse a shared operating model for release, SOP, onboarding, and escalation readiness.
- Why
- A feature is not operationally ready until the customer and internal paths around it can function.
07 · How it was delivered
From model to working system
- Mapped the six-stage product workflow and the dependencies between project, scene, review, render, and export states.
- The product combined a user-facing creation workflow with a separate rendering path, persistent project state, review-before-render controls, and production deployment constraints across Supabase and Vercel.
- Set reliability and review expectations across the Next.js application, Railway worker, Supabase storage and job state, Remotion composition, and FFmpeg muxing and export path.
- Structured product development, release readiness, market handoffs, SOPs, onboarding, and escalation in ClickUp.
- Directed AI-assisted implementation and GitHub review against architecture constraints and acceptance evidence.
Guardrails
Where the system must stop
- Do not describe a queued render as a completed customer output.
- Do not let stage transitions silently discard project or scene state.
- Do not mark release-ready without operational and customer-path evidence.
08 · What changed
What changed
- The workflow became easier to follow from input to export.
- Review happened before expensive rendering.
- Product and business handoffs became explicit.
- Render and finalization responsibilities became clearer.
- Launch readiness, SOPs, and escalation paths became visible.
- Implementation decisions were tied to product reliability and user output.
09 · Public evidence
What the public record can show
Evidence is described conservatively. Any visual proof added to this page must be redacted, captioned, and checked before publication.
Diagram
Six-stage workflow map
Shows the connected path from script through export and the review boundary at each material transition.
Sanitized evidence
Delivery operating model
A sanitized reconstruction of readiness, handoff, SOP, onboarding, and escalation structures.
Narrative record
Architecture rationale
Explains why scene state, review safety, worker behavior, and final output are treated as one product path.
10 · What this proves