How to demo a b2b SaaS product from your repo

Open any "how to demo a B2B SaaS product" guide and the first thing it measures is delivery: how confident you sound, how smooth the click-through feels, whether you remembered to mute Slack. Fair criteria. Also the wrong ones. This article looks at ownership instead: whether the demo lives in your repo, whether your agent can update it when the product changes, and whether you can re-prompt a buyer-specific variant without rebuilding anything. That's the actual workflow for how to demo a B2B SaaS product without creating a maintenance job on the side.

Why most B2B SaaS demo guides optimize for the wrong thing

The feature-tour trap

Most demo advice starts with completeness: show every major capability, walk every screen, leave no feature unexplained. The logic is simple enough. More coverage means fewer objections. In practice it produces a 40-minute walkthrough that tells the buyer nothing about whether the product solves their problem.

A B2B SaaS demo is a qualification tool, not a product tour. The buyer doesn't need to see the whole product. They need one moment where they think "that's exactly my situation." Everything before that moment is setup. Everything after it is noise. HBR's research on B2B buyer behavior shows that buyers who feel understood in the demo stage advance; buyers who feel demoed at don't. That's not a delivery problem. It's a structure problem.

What ownership changes

The second thing most guides miss is where the demo lives. A demo locked inside Supademo's SaaS or Arcade's platform is a recording. It captures a moment in time, and the moment your product ships a UI change, the recording shows the old version. Updating it means re-capturing every affected screen.

A repo-native demo is different. The demo is code — HTML, assets, flow logic — sitting in a folder next to your product. Your agent can read it, edit it, and re-prompt a new variant without touching a capture tool. A minimal demo repo looks like this:

That structure is the base everything else in this guide builds on.

Set up the demo repo before you ever take the call

The minimum structure you need

Before you run a single B2B SaaS demo, the repo needs four things: a flow file, captured assets or HTML steps for each screen, a data seed file, and a short notes file for persona-specific context. Nothing else. The Vercel Next.js SaaS starter templates — like the Auth0 + Next.js starter — show the same principle applied to product code: one source of truth, predictable structure, editable by anyone on the team. The demo repo follows the same logic.

Don't build more than one flow to start. One path, one buyer problem, one outcome. Add a second flow only when you have a second ICP with a genuinely different job-to-be-done.

Seeded data, permissions, and safe defaults

The demo environment needs synthetic data that looks real — company names, user counts, dollar figures, dates — but touches nothing live. A `seed-data.json` file with a handful of fake accounts and transactions is enough. Set role-based access so the demo user can only reach the screens you intend to show; anything outside that path should 404 gracefully, not expose a live customer record.

Two guardrails matter here: never use real customer data in a demo environment, and never hardcode a prospect's name directly into the flow file. Both belong in `seed-data.json`, where your agent can swap them per call with a single prompt.

Capture one product flow, then make it reusable

Pick the path that answers the buyer's actual question

The right demo flow is the shortest path from "here's your problem" to "here's proof we solve it." Not the most impressive path. Not the one that shows the newest feature. The one that answers the specific question the buyer will be asking in the first five minutes of the call.

For most B2B SaaS products, that's one or two screens deep. The rest of the product — the settings, the integrations, the edge-case flows — stays out. If the buyer asks about something you didn't show, that's a good sign. It means they're engaged enough to want more. That's the moment to ask a question back, not click to another screen.

Turn that flow into something your agent can maintain

This is where repo-native demos pay off. Say your nav restructures and "Reports" moves from the sidebar to a top tab. On a screenshot-based tool, you re-capture every screen that shows the sidebar. In your repo, you open the flow file and re-prompt:

"The Reports nav item has moved from the left sidebar to the top tab bar. Update every screen in the flow that shows the sidebar to reflect the new layout."

The agent edits the affected HTML steps in place. No re-capture pass, no manual click-by-click fix. The diff is reviewable in git before anything goes live. PostHog's B2B SaaS metrics guide makes a related point about instrumentation: the artifact that's hardest to keep accurate is the one that lives furthest from the code. The same principle applies to demos.

Make the B2B SaaS demo conversational, not scripted

Ask questions before you click through

The first two minutes of a demo call are the most valuable two minutes you have, and most founders waste them clicking through slides. Instead, ask the buyer what their current workflow looks like for the problem your product solves. Ask what "good" looks like for them in six months. Ask what the one thing is that would make them say no.

Those answers tell you which part of the demo to show first, which screen to linger on, and which part to skip entirely. The demo becomes a response to what you just heard, not a presentation you prepared in advance. That's what "tailored" actually means: not a logo swap, but a different entry point into the same flow based on what the buyer just told you.

Stop at the point where trust beats completeness

The demo should stop before the buyer runs out of questions. The right stopping point is the moment when the buyer has seen enough to form a real opinion — enough to push back, enough to ask "how does this handle X?" That question is the signal. It means they're evaluating, not just watching.

When that question lands, stop clicking and answer it. Then ask one back. The demo has done its job. Everything after that point is either a live product walkthrough, which is a different meeting, or noise that muddies the clarity you just built.

Update the demo when the UI changes without starting over

What changes first: copy, layout, or flow

Product changes fall into three categories for demo maintenance purposes. Copy changes — button labels, empty states, in-app messaging — are the smallest unit. Layout changes — nav restructures, sidebar collapses, tab reorganizations — affect multiple screens. Flow changes — a feature moves behind a new gate, a step gets removed, a new onboarding sequence ships — require rethinking the path itself.

Copy changes are one-line edits. Layout changes are a re-prompt across affected screens. Flow changes are a conversation with your agent about which path still proves the value fastest. None of them require starting over.

Why repo ownership makes the update cheap

When the B2B SaaS demo is code in your repo, every update is a diff. You can see exactly what changed, review it before it goes to the next prospect, and roll it back if something looks wrong. The maintenance cost scales with the number of affected screens, not with the total size of the demo.

On a capture-based tool, the update cost is fixed per screen regardless of how small the change was. You re-capture the whole screen because the tool has no smaller unit of edit. On a repo-native demo, the agent edits the specific element that changed and leaves everything else untouched. That difference compounds across every release cycle.

Where Inkly comes in

The structural problem this guide keeps circling is that most demo tools make the demo a recording: a moment in time, locked in their platform, updated by re-capturing screens. That model works for the first demo. It breaks down the week after launch, when the product ships a change and the demo shows the old version to the next prospect.

Inkly is built on the opposite premise. The demo is code you own — HTML, assets, flow logic — created by your coding agent (Cursor, Claude, Codex) and living in your repo next to the product. When the UI changes, you re-prompt the existing demo code instead of re-capturing screens. When a new prospect wants their company name and data in the flow, you prompt a variant off the base code instead of rebuilding from scratch. Inkly's Chrome extension gives you the same fast first-capture speed as Supademo; the difference is what happens after that first capture. The demo stays yours, in your repo, editable by your agent, so every update costs a prompt, not a re-record. The one honest tradeoff is that you need a coding agent set up (Cursor, Claude, Codex). If you don't have one in your workflow yet, the bring-your-own-agent path adds a setup step.

FAQ

Q: How do I demo a B2B SaaS product without giving a generic feature tour?

Start with a question, not a click. Ask the buyer what their current workflow looks like for the problem you solve, then show the one or two screens that prove you solve it. The demo's job is to answer their specific question, not to walk every feature in sequence. A buyer who finishes the demo with a real objection or a follow-up question is a buyer who was engaged. That's the outcome to aim for.

Q: What should I prepare before the call so the demo feels tailored to the prospect?

Four inputs: their role, their current workflow for the problem, the objection they're most likely to raise, and what success looks like for them in six months. Those four answers tell you which screen to open first, which part of the flow to linger on, and which part to skip. Write them in `persona-notes.md` before the call and update the file after.

Q: How do I make the demo repeatable and accurate as the product changes?

Keep the demo as code in your repo with a clear folder structure: flow file, captured assets, seed data, persona notes. When the product ships a UI change, re-prompt your agent against the existing demo code to update the affected screens. Version-control the demo alongside the product so every update is a reviewable diff, not a manual re-capture pass.

Q: What is the simplest workflow for a founder or product engineer to run demos without rebuilding them every week?

One demo flow, one source of truth in the repo, one agent that updates it. Capture the core path once — the shortest route from the buyer's problem to proof you solve it. Store it as code. When the product changes, re-prompt the agent for the affected steps. When a new prospect needs a variant, re-prompt for their context off the same base. Three prompts replace three recurring maintenance jobs.

Q: How do I personalize the pitch for different stakeholders like users, champions, and decision-makers?

The entry point changes, not the demo. For a daily user, open on the workflow screen that saves them the most time. For a champion, open on the outcome metric their boss cares about. For a decision-maker, skip the workflow entirely and open on the ROI screen or the integration that connects to their existing stack. The same flow file handles all three. `persona-notes.md` tracks which entry point fits which audience.

Conclusion

Stop treating the demo as a disposable asset you rebuild before every call. Put it in the repo, give it a real structure, and let your agent maintain it. The demo that stays accurate across releases is the one that earns trust on the call, because what the prospect sees matches what they'll get when they sign up. This week: pick one flow, put it in `/demo`, and update one step with your agent. That's the whole system.