How to Demo a Developer Tool, CLI or API on Video

Developer products are hard to show because the interesting part is often invisible. Here's how to make terminals, code and API calls readable on video, and what developers actually want to see.

A SaaS dashboard is easy to put on video. There are buttons, charts and something to click. A CLI, an SDK or an API is harder. The product is a command, a few lines of code or a JSON response, and the useful part (what it saves you from doing) doesn't appear on screen at all.

This post covers how to plan and lay out a demo for a developer product so it's readable, honest and short.

Disclosure: I build DemoVexa, a tool that can turn your code into product demo videos. Most of this post is about planning and readability, which applies whatever you use.

Key takeaways

• Show the problem, the smallest working example and the result. Developers care about how few steps it takes.
• Terminal and code text must be readable on a phone: large font, short lines, and only the lines that matter.
• Show real commands and real output shapes, using sample data. Don't fake output your tool can't produce.
• Pair the video with copyable code in the post or README, because nobody can copy text out of a video.

Contents

• Key takeaways
• What do developers want to see in a demo?
• How do you structure a developer tool demo?
• How do you make terminal and code text readable?
• How do you show an API, which has no UI?
• Should you record your terminal or animate it?
• What should go in the post or README alongside the video?
• A few common mistakes
• FAQ

What do developers want to see in a demo?

Developers watching a demo are usually asking a few practical questions:

• How do I install it? One command, or a long setup?
• What's the smallest thing that works? The "hello world" of your tool.
• What does the output look like? Real shapes, real errors, real formats.
• How does it fit my stack? Language, framework, CI, editor.
• What does it replace? The script or manual step they do today.

A good developer demo answers three or four of these and skips the marketing.

How do you structure a developer tool demo?

A simple structure that works for most CLIs, SDKs and APIs:

Part	What's on screen	Rough share of the video
The problem	The manual way, or the error people hit today	10 to 15%
Install or setup	One command or one config block	10 to 15%
The smallest example	The core command or a few lines of code	30 to 40%
The result	Output, a file created, a dashboard updated	20 to 30%
Where to go next	Docs link, repo, a more advanced example	5 to 10%

Keep it short. A 60 to 90 second demo of one task usually beats a ten minute tour.

How do you make terminal and code text readable?

Most developer demos fail on readability, not content. Text that's fine on your monitor is unreadable on a phone or in a small embedded player.

• Large font. Bigger than you think. Test by watching the video on your phone.
• Short lines. Wrap long commands, or use shorter example paths and names.
• Fewer lines. Show the five lines that matter, not the whole file.
• Highlight the change. When one line matters, highlight or zoom on it.
• High contrast. A plain dark or light theme, not a busy custom one.
• Slow typing, or none. Real typing speed is too fast to follow. Either type slowly or show the command appearing line by line.

How do you show an API, which has no UI?

An API demo needs something visible on both sides of the call. Common options:

1. Request and response side by side. The request on the left, the formatted JSON response on the right.
2. Code, then effect. A few lines of SDK code, then the thing it changes, such as a record appearing in a dashboard.
3. A sequence diagram. For flows like authentication, a simple animated diagram of who talks to whom.

Use sample keys and sample data. Never show real tokens, even expired ones. The API authentication demo guide on the DemoVexa blog goes deeper into showing auth flows without exposing secrets.

Should you record your terminal or animate it?

Both are reasonable, and the choice depends on the tool:

• Record when the real behaviour is the point: timing, streaming output, an interactive prompt.
• Use a terminal recorder that saves text rather than pixels when you want sharp, resizable output for docs.
• Animate when you want a polished, narrated video that matches a script line by line and survives UI or output changes.

For animated videos, some tools turn your code into product demo videos instead of recording anything. For a developer product, that means recreating the terminal and output as animated scenes with sample data, then timing them to a voiceover. The tradeoff is that the output on screen is a recreation, so check that it matches what your tool really prints.

There's a longer walkthrough of how to make a demo video for a CLI tool on the DemoVexa blog.

What should go in the post or README alongside the video?

The video gets attention. The text gets people to actually try it. Next to the video, include:

• The install command as a copyable code block.
• The smallest working example from the video, exactly as shown.
• A link to the full docs.
• Version numbers for anything version sensitive.

A few common mistakes

• Starting with the architecture instead of the result.
• Using a real project with long, messy paths on screen.
• Showing output your tool doesn't actually produce, or hiding errors it does produce.
• Talking over a silent, static terminal for 20 seconds.
• Forgetting that viewers can't copy anything from a video.

FAQ

How long should a developer tool demo video be?

For one task, 60 to 90 seconds is usually enough. Longer tutorials work on YouTube or in docs, but a short demo of the core workflow is better for a README or landing page.

How do I make terminal text readable in a demo video?

Use a large font, a high contrast theme and short lines, and show only the lines that matter. Watch the result on a phone before publishing.

How do you demo an API that has no user interface?

Show the request and response side by side, or a few lines of SDK code followed by the visible effect. For auth flows, an animated sequence diagram can explain who talks to whom.

Should I show real API keys in a demo?

No. Use sample or obviously fake keys and sample data, even if a real key is expired or scoped.