How to Build Product-Driven Video Variations With VideoFlow

If you need one source to generate multiple product videos, the cleanest pattern is to make the product data the contract and VideoFlow the renderer. You author the template once, compile it to VideoJSON, and reuse the same structure for browser export, server jobs, and review without rebuilding the timeline for each variant.

Start with the main site at VideoFlow, then keep the docs, core, renderers, React video editor, playground, and examples open while you build.

If you want the broader JSON-first context, pair this with How to Build a JSON-First Video Workflow With VideoFlow, How to Build a Portable Video Export Pipeline in VideoFlow, How to Keep Browser, Server, and Editor in Sync With One VideoJSON File, and How to Build a Git-Friendly Video Template System With VideoFlow.

1. Decide What the Template Should Accept

A reusable video template starts with a small, strict data contract. Do not begin with motion or effects. Begin with the few fields the template actually needs so the same project can generate product launch clips, ad variations, or demo videos without becoming a custom one-off.

A useful product record usually includes the product name, a hero image, one benefit statement, one proof point, and a clear CTA. If the video is for a launch or promotion, add price data only when you can keep it accurate.

const product = {
  name: "Magnetic Desk Lamp",
  benefit: "Soft light for focused work",
  price: "$79",
  cta: "Shop now",
  heroImage: "https://example.com/product.jpg",
};

Expected result: every downstream scene knows exactly which fields it can rely on.

If you want a simple mental model, think of the product record as the brief and the scene as the reusable implementation. That keeps the template generic enough to reuse while still being specific enough to stay on brand.

2. Build One Scene in @videoflow/core

Once the data contract is clear, author the scene in @videoflow/core. The point is not to hardcode a final MP4. The point is to store the structure in a form that can be compiled, diffed, and reused later.

import VideoFlow from "@videoflow/core";

const $ = new VideoFlow({
  name: "Product variation",
  width: 1920,
  height: 1080,
  fps: 30,
});

$.addImage({ src: product.heroImage });

$.addText(
  { text: product.name, fontSize: 7, fontWeight: 800 },
  { transitionIn: { transition: "overshootPop", duration: "500ms" } }
);

$.addText({ text: product.benefit, fontSize: 4 });
$.addText({ text: product.cta, fontSize: 3, fontWeight: 700 });

const videoJSON = await $.compile();

Expected result: you get a portable JSON object instead of a one-off render result.

If you want the JSON-first version of this pattern, the companion article How to Build a Portable Video Export Pipeline in VideoFlow shows the same idea from the renderer side, while How to Build a VideoFlow Project That Keeps Templates and Renderers Separate shows how to keep the template layer clean.

3. Render the Same JSON in the Right Place

VideoFlow becomes useful when the same JSON can drive more than one runtime. Use the browser renderer when the user is already in your app and clicks export. Use the server renderer when the job belongs in a queue, a batch process, or a scheduled workflow. Use the DOM renderer when you want a live, scrubbable preview that stays in sync with the project.

The practical difference is operational, not structural:

• Browser renderer for low-friction client-side export.
• Server renderer for queue workers, API jobs, and scheduled renders.
• DOM renderer for preview and frame-accurate review.

The product docs also call out browser export progress callbacks and AbortController cancellation, which matters when a user changes their mind mid-export. On the server side, the renderer uses headless Chromium and WebCodecs by default, with FFmpeg available for alternate encoding needs.

Expected result: you stop rewriting timelines for each runtime and start choosing a renderer by job type.

If you want the renderer decision rule in a separate walkthrough, read How to Keep Browser, Server, and Editor in Sync With One VideoJSON File and How to Build a Portable Video Export Pipeline in VideoFlow.

4. Add the React Editor Only When a Human Needs to Adjust It

If the product team needs to tweak text, keyframes, or layer order, add the optional React editor instead of inventing a second project format. That keeps the timeline, preview, and export path tied to the same underlying JSON.

import { VideoEditor } from "@videoflow/react-video-editor";
import "@videoflow/react-video-editor/style.css";

export default function App() {
  return (
    <VideoEditor
      video={videoJSON}
      onChange={(next) => saveToServer(next)}
      onSave={async (next) => await persist(next)}
      onUpload={async (file) => await upload(file)}
      theme="dark"
    />
  );
}

Expected result: a designer, marketer, or operator can make a visual edit without creating a parallel data model.

The editor is most useful when the project needs a review pass. It gives you a multi-track timeline, undo and redo, file upload callbacks, and MP4 export, which is usually enough for a non-developer to make a safe adjustment and hand the project back.

5. Keep Variations Reviewable in Git

The fastest way to make video automation brittle is to let each variation grow its own hidden structure. The safer pattern is to keep one template file, one data file, and one review path. Then the only things that change from variant to variant are the fields that should change.

That is where a Git-first workflow pays off. When a reviewer can see that only product data changed, the diff is easy to trust. When the scene structure changes too, the review becomes slower and the risk goes up. For a deeper take on the template side, pair this with How to Build a Git-Friendly Video Template System With VideoFlow.

A simple rule keeps the workflow honest: if you cannot explain the variation as a data change, it probably needs another review pass before it ships.

6. Use the Same Template for Launches, Ads, and Product Demos

Once the contract and scene are stable, the template can serve more than one job. A product launch clip can use the same layout as a paid social variation. A product demo can use the same structure as a customer-specific video. A seasonal promo can reuse the same scene with only the offer text changed.

That is the real value of VideoFlow for product teams: one project can support repeatable video output without turning the rendering pipeline into a pile of custom edits. If you want to explore the toolkit directly, start with the playground, the docs, and the examples. If you want the source, the project is open on GitHub.

The shortest path is simple: define one product record, build one VideoFlow scene around it, choose the right renderer, then let the editor and Git review flow handle the rest.