Product demo for indie hackers: it's code you own

Open the last demo you sent a prospect. Now open your live product in another tab. Count the things that don't match.

The best product demo for indie hackers isn't the prettiest one. It's the one that still matches your product after you ship. That means it lives in your repo, next to your app, where an AI coding agent can update it the same way it updates everything else. This article shows you how to pick the format, build the structure, keep it current without re-recording every week, and put it where it actually converts.

Why a product demo for indie hackers should live in your repo

When the demo and the app stop matching

You ship a UI change on a Thursday. The demo still shows last week's nav. A prospect clicks through on Friday, sees a flow that doesn't exist, and closes the tab. You find out later, or you don't find out at all.

That's the usual failure mode for any demo stored as a recording outside your codebase. The product moves. The demo doesn't. And because the demo lives in someone else's SaaS, every fix means opening a separate tool, re-recording the affected screens, and re-publishing. Most founders just leave the stale demo up.

What changes when the demo is code you own

When the demo is code in your repo, in a folder sitting beside `/src` the way your tests or docs do, it moves with the product. PostHog's approach to internal tooling reflects the same instinct: own the artifact, don't rent it.

More practically: Cursor, Claude Code, or Codex can read your app code and your demo code in the same context. Ask the agent to update the demo after a UI change and it can diff the two, find the mismatch, and fix it. No separate tool. No separate login. No re-record.

A repo tree with a `/demo` folder beside `/app` is enough. The demo becomes just another part of the workflow.

Pick the demo format that fits how your product actually sells

Screen recording, animated mockup, or interactive product demo

Each format has a job. A screen recording is a video. It is quick to make, easy to share, and frozen the moment you hit record. An animated mockup, like a GIF or motion design, is even more static. It works for a feature highlight, but it is not much help for showing a real workflow. An interactive product demo lets the viewer click through the actual flow. That's the closest thing to handing someone the product.

The right format depends on one question: how often does your product change? If you ship every week, a recording is already out of date by the time the next sprint ends. An interactive demo built as code updates with a prompt.

Why technical products can still use a simple recording

A CLI tool, a developer API, or a data pipeline can demo well in a screen recording because the value is visible from the output. If your product gives you a clean terminal result or an obvious before/after, a 90-second Loom works fine for the first few prospects.

It stops working when the output changes, when the UI wraps the API, or when a prospect wants to try a path the recording does not show. At that point, an interactive product demo, one the viewer can navigate, handles the objection the recording cannot.

Build the minimum viable demo structure that gets to signup

The first three screens the reader actually needs

The fastest structure that converts is three beats: the problem, the proof, and the payoff.

Screen one shows the situation the prospect is already in, in their terms. Screen two shows the product solving it in the fewest clicks possible. Screen three shows the outcome: the number, the saved time, the thing they came for. That's it. No tour-guide language, no feature checklist, no "and here you can also."

Research on conversion behavior keeps pointing the same way: the faster a visitor reaches the value moment, the higher the signup rate.

What to cut when the demo gets too clever

The most common overbuild is branching paths the viewer never takes, explanatory tooltips on every element, and a five-click setup before anything interesting happens.

Cut any screen that does not move the problem-proof-payoff arc forward. Cut any tooltip that explains a UI element instead of the outcome it produces. If the demo takes more than eight clicks to reach the payoff, remove screens until it does not. The goal is a viewer who reaches the end and thinks, "I want to try that," not someone who finishes a tour and feels vaguely informed.

Use Cursor, Claude Code, or Codex to author the demo faster

How to turn rough MVP code into a pitch-ready demo

The AI-assisted demo workflow starts with the repo, not a blank canvas. Open your codebase in Cursor or Claude Code, point the agent at the core user flow, the two or three screens that show the product's main job, and ask it to generate a demo path from that code.

The prompt does not need to be fancy. Something like "create a clickable demo of the onboarding flow, three screens, using the existing components" gives the agent enough context. The output will be rough. That's fine. You're not recording; you're generating a starting point you can edit.

One pass through the no-code editor to adjust labels and trim extra screens, and the demo is shareable. The whole process is faster than re-recording from scratch because the agent already knows the product. It's reading the same code that runs it.

The repo layout that makes agent edits easy

The `/demo` folder lives at the same level as `/src`. The `demo.config.ts` file holds the screen order, the copy for each step, and any personalization variables. The README explains what the demo shows and which screens map to which product flows.

When you ship a UI change, open the repo in your agent, reference both `/src` and `/demo`, and ask for a diff. The agent finds the mismatch and proposes the update. You review, approve, and push. No separate tool. No re-record.

Keep the product demo accurate without re-recording every week

The weekly change workflow

For a product that ships often, the maintenance loop is simple: update the app, run the agent against `/demo`, check the diff, push.

The trigger is any change that affects a screen the demo shows, like a renamed label, a restructured form, or a new step in the onboarding flow. You do not need to audit the demo manually every week. You need to make "update the demo" part of the same commit or PR that ships the product change.

What an agent updates and what still needs review

An AI coding agent handles the mechanical updates well: copy changes, label renames, screen reordering, personalization variable swaps. It can update `demo.config.ts` to reflect a renamed nav item without touching anything it shouldn't.

What still needs a human pass is the narrative arc. If a product change adds a new capability that belongs in the demo's proof screen, the agent will not know to promote it. It will just update what exists. Check the problem-proof-payoff structure after any significant feature release. The agent maintains the demo; you maintain the story.

The before-and-after diff that proves the process

A typical commit after a UI change looks like this:

Three files, one agent pass, five minutes. The demo matches the product again before the next prospect opens it.

Put the demo where it actually gets used

Landing page placement that reduces friction

The demo belongs above the fold or one scroll below the headline, not buried after three paragraphs of copy. A visitor who lands on your page and cannot find the demo in the first ten seconds reads the copy instead, and copy converts worse than a working demo.

Embed the demo inline if you can. Do not hide it behind a "Watch demo" button unless you have to. Every extra click is another chance to lose someone. If the demo needs a click to launch, make the thumbnail the most interesting screen in the flow, the proof screen, not the login screen.

The DM version for customer-facing founders

When you're sending the demo in a message instead of embedding it on a page, the structure changes. You get one sentence to explain why the recipient should click. Write that sentence in terms of their problem, not your product. "Here's how [product] handles [their specific situation]" beats "Here's a demo of [product]" every time.

The DM version should be shorter than the landing page version, five screens maximum. The viewer is on their phone or in a Slack thread. Get to the payoff in three clicks.

What to measure after launch

Track starts, clicks, and signups. Did they open the demo? Did they advance through it? Did they convert after? Views alone tell you nothing. A view that does not start the demo is just a bounce with extra steps.

If starts are high but signups are low, the demo is getting opened but the payoff is not landing. Tighten the proof screen. If starts are low, the placement or the thumbnail is not pulling its weight. Fix the entry point before you fix the content.

Where Inkly comes in

The problem this article describes, a demo that goes stale every time the product ships, exists because most demo tools store the artifact in their own SaaS. You captured it there, it lives there, and updating it means going back there. Every UI change is a separate trip.

Inkly is built on the opposite premise: the demo is code you own, in your repo, next to your app. You build it once, via Chrome-extension capture or by prompting your own coding agent, and every later update costs a prompt instead of a re-record. When your product changes, you ask the agent to refresh the demo. It reads both codebases, finds the mismatch, and fixes it.

The honest catch is that Inkly's MVP requires a coding agent (Cursor, Claude Code, or Codex) and a repo workflow. If you are not already working that way, the bring-your-own-agent path adds setup. But if you are already in the repo every day, the demo becomes code you maintain like everything else. No separate tool. No re-record. No stale demo on Friday.

FAQ

Q: What kind of product demo works best for an indie hacker: screen recording, animated mockup, or interactive demo?

It depends on how fast your product changes. A screen recording is fine for a stable CLI tool or a data output where the value is obvious from the flow. An interactive demo is better for anything with a UI that ships regularly. It can be updated without re-recording, and it lets the viewer navigate their own path through the product.

Q: How do I make a demo instantly understandable without overexplaining features?

Cut to the outcome. Every screen should show what the user gets, not what the product does. Remove any tooltip or label that explains a UI element instead of the result it produces. If a viewer cannot understand the value from the screens alone, add one line of context per screen, not a paragraph.

Q: What is the simplest structure for a demo that leads to signup instead of confusion?

Three screens: the problem state the prospect recognizes, the product solving it in the fewest clicks, and the outcome they came for. That arc, problem, proof, payoff, is the shortest path from "I'm curious" to "I want to try this." Everything else is extra.

Q: How can I keep the demo accurate when the product changes every week?

Store the demo as code in your repo, next to your app. When you ship a UI change, run your coding agent against both folders, review the diff, and push. The demo update becomes part of the same workflow as the product change, not a separate task you remember later.

Q: How do I turn a rough MVP into a pitch-ready demo with minimal time and tooling?

Point a coding agent at your core user flow and ask it to generate a demo path from the existing components. The output will be rough. Edit it in a no-code editor, trim it to three to five screens, and ship. You're not building a polished product tour. You're building the shortest path to the value moment.

Q: What should a customer-facing founder send instead of repeating the same explanation on calls?

A short interactive demo, five screens maximum, framed in terms of the recipient's specific problem. Write one sentence before the link that names their situation, not your product. The demo handles the explanation. The sentence earns the click.

Q: How do I demo a technical product to a technical audience without making it boring?

Show the output, not the setup. Technical audiences care about what the product produces: the result, the diff, the saved step. Start with the outcome screen and work backward. Skip the onboarding flow unless it is the product's actual value. A 60-second path to a clean result beats a five-minute tour every time.

Conclusion

Go back to those two tabs. If the demo and the product do not match, the fix is not to re-record. It's to move the demo into the repo and let the agent maintain it from there. Pick one demo path this week, drop it in a `/demo` folder, and update it against the next product change you ship.