Applied AI · 2026
VideoHub — three content lines on one render and asset base
A content production matrix rather than a video editor: article, video and MP4 lines share one render queue and asset base, and multi-language with multi-aspect output is generated as a Cartesian product from a single form.
The situation
Content production for a B2B site looks like a creative problem and is mostly a logistics problem. One product page becomes a video, the video becomes a vertical cut, the vertical cut becomes three language versions, and the next month it all changes again. Each of those steps is a separate edit, and every edit is a person opening an editor and re-deciding the same things.
The brief for this project was not “make better videos”. It was: how many outputs can be produced from one input, by people who are not video editors, without the quality collapsing.
The call we made
The unit of work is a render job, not a video. The shared base is a render queue with retry, an asset library and versioning. That sounds like infrastructure detail, but it is where the economics sit: most of the engineering in a content factory is re-rendering the same twenty seconds two hundred times with different text, language and aspect. Treating that as the product — queue, retry, asset reference, deterministic output — is what makes batch production possible at all.
One form, a matrix of outputs. Language and aspect ratio combined are a Cartesian product, and the count grows multiplicatively: three languages by two aspects is six videos from one submission. Manual editing at that growth rate is not a cost problem, it is a scheduling problem, because every version is another chance to ship a stale price or a wrong logo. The matrix is therefore generated, never re-edited. Output count is a parameter of the job.
The studio is a form, not an editor. This is the decision with the clearest trade-off. An editor invites frame-level revision, and a product that accepts frame-level revision becomes a video editor — a different product with a different cost structure and a different user. A form constrains inputs to what the render graph can actually honour: text length, asset slots, safe areas, aspect rules. Output stays reproducible and batchable, and quality stays inside bounds. The cost is control: a client who needs frame-level direction needs a different tool, and we say so.
Freeze baselines. The enterprise video baseline is frozen at V0.3; the promotional video line is at M0–M4; the music line at P0–P17. A content product that keeps changing cannot be priced, scheduled, or handed to a customer, and every line has to have a version that other work can depend on.
Share the base, not the surface. Three lines sit on the same render and asset base: promotional video, enterprise video, and music with vertical and MV variants. The digital human and TTS chain plugs into the same base. The second line then costs a fraction of the first, which is the whole reason to build a matrix instead of three tools.
What we built
- video-hub, the promotional video studio — a React studio form feeding FastAPI and SQLite into Remotion rendering; multi-language and multi-aspect Cartesian output; M0–M4 complete.
- video-studio, the enterprise video baseline — web studio with an Ubuntu private deployment, PostgreSQL, Redis and Celery; version 0.3 frozen as the baseline other work builds against.
- music-hub, the music line — Python generation of MP3 and MP4 output, packaged download and in-browser playback, MV motion and a 9:16 vertical version per track; P0–P17 complete.
- article-hub, the article line — topic selection, drafting, illustration and publishing across a three-part front end, middle layer and back end; in progress.
- Shared services — render queue with retry, asset library and version records, voice and digital human generation, template versioning.
Inside the studio the two rendering routes are priced separately and visibly: an edited fast cut assembled from layout and FFmpeg, in the region of 25 to 30 seconds of render time, and a motion route on Remotion at roughly 5 to 8 minutes. The estimated cost is shown before the job is submitted and each run carries a budget cap, so a batch cannot quietly become an expense.
Result
The video line produces multi-language, multi-aspect sets from a single submission, which is the commercial point: a campaign that used to be six editing jobs is one form and one queue. The music line is complete through its planned phase list, and the enterprise baseline is stable enough to be a dependency.
The honest status: this is a mixed-maturity product, and the article line is not finished. The known costs are unchanged by any of the above — render time and compute cost per output, the quality ceiling of multi-language dubbing, and asset copyright, which is the one that most often stops a batch from shipping. Those three are why the product is positioned as an internal production base with a private-deployment option rather than a public self-serve tool.
Technology
| Stack | React · FastAPI · SQLite · Remotion · PostgreSQL · Redis · Celery |
|---|---|
| Delivery model | Web studio, private deployment option |
| Client | Internal product, used for marketing and client content |
| Status | In progress |
What we cannot show
Internal product line at mixed maturity. The video studio link runs; the article line is still in progress. Maturity is stated per line rather than for the product as a whole.
Similar problem?
If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.