The product video playbook

Your codebase is the best brief for a product video

Why the repository beats the marketing site as the source for a product demo video, and how to get the story, the screens and the brand out of it.

Most product videos start from the marketing site, because that is where the approved words live. But the site is a summary written for strangers, and it stops at the sign-in button. Everything a demo actually needs to show — the screens, the workflow, the moment the product does its job — sits behind it, in the code.

That used to be a curiosity, because nobody writing a video brief was going to read a repository. It matters now because coding agents do read repositories, quickly and thoroughly, and they can run the app too.

What each source can and cannot give you

SourceGives youMissesBest for
Marketing websitePositioning, approved claims, public imageryEverything behind the login; the real workflowBrand films and first cuts
Screen recordingThe real workflow, in motionPolish: dead air, cursor wander, real data on screenWalkthroughs, support videos
ScreenshotsFaithful product screensInteraction: they can only be panned and zoomedShort demos, native apps
DOM captureScreens as elements and text — clickable, re-typeableNative and desktop apps; needs the app runningDemos where the product is used on screen
The codebase itselfReal feature names, every route, design tokens, logo filesCustomer outcomes and proofThe brief and the screen list

The pattern is that the codebase is the best brief and a DOM capture is the best footage, while the website remains the best source of positioning. A good demo uses all three and does not ask any of them to do another's job.

Getting the brief out of the repository

Writing a product video brief from a codebase

  1. Name the product in one lineStart from the README and the package description, then correct them against what the code actually does. Descriptions drift; routes do not.
  2. List the real screensThe routes or pages directory is the product's table of contents. Pick the three or four where the outcome is visible — the before, the action, the result — not the ones with the most engineering behind them.
  3. Use the product's own wordsFeature names, button labels and empty-state copy are in the components. A film that says "Boards" when the app says "Boards" reads as the product; one that says "project spaces" reads as an advert.
  4. Take the brand from the source of truthTheme files, CSS variables and Tailwind config hold the exact colours and type. Logo files — ideally SVG, in light and dark versions — are usually in public/ or assets/.
  5. Find the story in onboardingThe first-run flow is the product team's own answer to "what should a new user do first". It is very often the right spine for a 30-second film.

Getting the screens out: screenshot or DOM

A screenshot is a picture of the screen. A DOM capture is the screen itself, frozen: the elements, their text and their computed styles, stripped of anything that could run. The difference only shows once the film tries to use the screen.

A cursor can click something real
With a DOM capture the film knows where the button is and what it says, so the click lands on it and the button can press. Over a screenshot the same move is approximated from pixels.
Text can change to fit the script
A label, a number or a customer name in a DOM capture is text. In a screenshot it is paint, and changing it means repainting the image.
The layout can adapt
A DOM capture can be re-rendered at a different size, which matters when one film is cut for widescreen, square and vertical.

The trade-off is that a DOM capture needs the app running in a browser. For native, desktop and mobile apps, or anything that will not run locally, screenshots and screen recordings are the honest answer.

Capturing well

  • Run against seed or demo data. Empty states make empty films, and real customer data is far harder to remove than to never capture.
  • Use a real desktop window, around 1440 by 900. A generous capture gives the film somewhere to move.
  • Wait for the screen to settle — data loaded, fonts in, animations finished — before capturing.
  • Capture states, not just pages: the dialog open, the filter applied, the result filled in.
  • Name each capture the way the product names it, so the storyline and the screen agree.

When the codebase is the wrong starting point

A brand film about why the company exists, a customer story, or a recruiting video is not about the product doing a job, and the repository has nothing to say about it. Start those from the website, from interviews, or from a person on camera — Loom, Descript or a real crew all do that better than any amount of captured UI.

The same goes for teams who want to hand-build every frame. Remotion lets a developer write a video as React code, and its agent skills teach coding agents to do the same. That route gives complete control in exchange for doing the direction, the script, the voice and the sound yourself.

Questions people ask

What should I read in a codebase to write a product video script?

The README and package metadata for the one-line description, the routes or pages directory for the list of real screens, the onboarding flow for the first-run story, and the pricing or plan logic for who it is for. Theme files and Tailwind config give the colours and type, and public/ or assets/ usually hold the logo.

Are screenshots good enough for a product demo video?

For a short film, often yes: a clear screenshot of the outcome carries a lot. They fall short when the film has to show the product being used, because a picture cannot be clicked, filtered or re-typed, so every interaction has to be faked over pixels.

What is a DOM capture of a web page?

A copy of the page as its elements, text and computed styles rather than as pixels, made inert so nothing in it runs. It can be re-rendered at a different size, and individual elements can be found and animated — which is what a demo needs.

Is it safe to capture screens from my local app for a video?

It is as safe as the data on the screen. Point the app at seed or demo data first; a captured screen shows exactly what was on it, and invented data is far easier than redacting real customers afterwards.

NextMake the film with your coding agentThe step-by-step version: connect the agent, let it capture your real UI, approve the storyline.

Keep reading

Your codebase is the best brief for a product video · Frame24