Your Codebase Already Contains Most of Your Demo Script

When developers plan a product demo, they usually start by opening the app and clicking around to remember how things work. That's a slow way to find information you already have in a more precise form: the code.

Your repository knows the name of every screen, the exact label on every button, the order of every flow, and what changed recently. A demo script built from those facts is more accurate than one written from memory, and it uses the same words the viewer will see on screen.

This is the same reading that tools which turn your codebase into a demo video do automatically, but it works just as well by hand. Here's where to look, and what each source gives you.

Key takeaways

• Your code already holds the screen names, exact labels, flow order and recent changes a demo script needs.
• Navigation gives the map, UI strings give the vocabulary, fixtures give the sample data and end to end tests give the flow.
• Git history shows what's new, and docs show what a feature is for. If code and docs disagree, fix that first.
• A one page plan built from these sources can be traced back to the code line by line.

Contents

• Key takeaways
• 1. Routes and navigation: the map of the video
• 2. UI strings: the vocabulary of the narration
• 3. Fixtures and seed data: what the screens should contain
• 4. End to end tests: the flow, already written down
• 5. Git history: what's actually new
• 6. Docs and how to guides: the intent
• Putting it together: a one page demo plan
• Letting a tool do the reading
• FAQ

1. Routes and navigation: the map of the video

Start with whatever defines your screens. In a React app that might be a router config, a pages or app folder, or a sidebar component that lists the main sections.

# Next.js app router: every page in the app
find app -name "page.tsx"

# A sidebar or nav config
rg -n "label:" src/components/Sidebar.tsx

The navigation tells you two things. First, the names of the main areas, exactly as users see them. Second, the shortest path to any screen. If your feature lives three levels deep, the demo needs a plan for getting there, or it should start on that screen directly.

2. UI strings: the vocabulary of the narration

The most common accuracy mistake in a demo is the narration calling something by a different name than the screen does. The voiceover says "download" and the button says "Export". The script says "workspace" and the app says "project".

If your app has translation files, those are a ready made glossary:

rg -n "\"export" locales/en.json

If it doesn't, search the components for the visible strings in the flow you're demoing. Copy the exact labels into your script notes. When you write narration later, use those words and only those words for UI elements.

3. Fixtures and seed data: what the screens should contain

Test fixtures and seed scripts are often the best sample data you have. They were written to exercise the feature, so they usually cover the interesting cases: an overdue invoice, a user without permission, an empty state.

Read them for two reasons. They tell you which data makes the feature look like itself. And they tell you what to avoid: if a fixture is named broken_user or full of placeholder text, it's a sign you need a cleaner demo dataset before anything goes on camera.

4. End to end tests: the flow, already written down

An end to end test is close to a demo script with the narration missing. It lists steps in order, names the elements a user touches, and asserts the result.

test("send an invoice", async ({ page }) => {
  await page.getByRole("link", { name: "Invoices" }).click();
  await page.getByRole("button", { name: "New invoice" }).click();
  await page.getByLabel("Client").fill("Northwind Studio");
  await page.getByRole("button", { name: "Send" }).click();
  await expect(page.getByText("Invoice sent")).toBeVisible();
});

Turn that into scenes and you have: open Invoices, start a new invoice, pick a client, send, see the confirmation. The last assertion is usually the moment the demo is built around.

5. Git history: what's actually new

For a feature launch or changelog video, the commit log tells you what changed and when. A quick look at recent history for the feature's folder is often enough:

git log -20 src/invoices

Look for the commit that introduced the user facing change, and read its diff. It tells you which screens changed, which strings were added, and sometimes why. That "why" is worth putting in the first line of your narration, if it's something a user cares about.

6. Docs and how to guides: the intent

Code tells you what the product does. Docs tell you what it's for. If you have a how to guide for the task you're demoing, it already describes the steps in user language and usually says who the feature is for. Use it to check that your scene order matches what you tell users in writing.

If the docs and the code disagree, fix that first. A demo that matches the code but not the docs will confuse people who read both.

Putting it together: a one page demo plan

After going through these sources, you can write a plan in a few minutes:

Add one line on top: who the video is for and the one thing they should remember. That's a complete brief, and every detail in it can be traced back to the code.

Letting a tool do the reading

This kind of reading is exactly what DemoVexa automates. You point a workspace at a local code folder (in any language), plus docs if you have them, and Claude reads it to learn the product's screens, names and flows before it drafts a brief and script. If the folder is a git repository, DemoVexa can also suggest video ideas from recent history. The docs page on choosing a code folder and docs for demo videos has practical advice on choosing the right folder and writing how to guides that turn into clear scenes.

Whether you do it by hand or with a tool, the principle is the same: the code is the most up to date description of your product you have. Start the demo there, not from memory.

FAQ

How do I list every page in a Next.js app?

With the app router, each route is a folder under app that contains a page file, so find app -name "page.tsx" lists them (adjust the extension if you use .jsx or .js). With the older pages router, the files under pages are the routes.

Can an end to end test be used as a demo script?

It's a good starting point. A test already lists the steps in order, names the elements a user interacts with and checks the result. You still need to add narration and decide which steps are worth showing.

How do I make sure the narration matches the labels in the app?

Copy the exact strings from your translation files or components into your script notes, and use only those words for UI elements. If the button says "Export", the voiceover should say "Export" too.

Can I make a demo video straight from a GitHub URL?

Not with DemoVexa. It reads a local folder, so you clone the repository to your computer first and point a workspace at that folder. Pull the latest changes before making a video about a new feature.