Async sales demo playbook for builders

A few months ago, I was running outbound for a B2B tool I had built solo. I put together a clean async sales demo, embedded it on the landing page, linked it in cold emails, and let it do its thing. It converted well enough that I stopped thinking about it.

Then I changed the pricing. Three tiers became two, the numbers changed, and the CTA copy changed too. The demo still showed the old pricing modal, word for word, to every prospect who clicked through.

I found out because someone replied asking why the pricing in the demo did not match the site. One reply. How many others just left?

The job is not making the async sales demo once. It is building it so it survives the next product change and keeps working across outbound, the landing page, and follow-up without a re-recording session every time something shifts.

What an async sales demo has to do besides play back a recording

The job is buyer enablement, not just a watchable artifact

An async product demo has one job: help a buyer research your product on their own time and move closer to a decision without needing a live meeting. That means it has to answer the obvious pre-call questions — what does this actually do, is it for me, what happens next — in under three minutes, without a sales rep on the line.

A demo that only plays back screens fails. It shows the product, but it does not guide the buyer. The ones that work have a clear path, a visible outcome, and a CTA that tells the buyer exactly what to do next.

Where the demo fits in outbound, the site, and follow-up

The same asset can do three jobs if it is built right:

• Cold outreach — embedded or linked in the first email, it replaces the "want to see a demo?" ask with a direct answer the prospect can act on immediately.
• Landing page — sits above the fold or in the hero and gives visitors a reason to stay past the headline.
• Post-call follow-up — sent after a discovery call, it reinforces what was discussed and gives the buyer something to share internally.

A16z's investment thesis on Loom noted that engineering and product teams create demos for reviews and training while sales teams use the same async format for follow-up — same asset, different surfaces. That reuse only works if the demo stays accurate. One stale version breaks all three channels at once.

Build the async sales demo once, from one prompt

Start from the buyer's task, not from a feature tour

Pick one thing the buyer needs to verify before they move forward — not "here's everything the product does." For a B2B SaaS, that is usually one of: "does this solve my specific problem," "can I see myself using this," or "is this worth a real conversation."

Build the demo path around that task. Five to seven screens. One clear outcome. If a screen does not help the buyer answer their question, cut it.

Turn that path into a buyer-ready asset with AI

The prompt-to-published flow, in plain terms:

• Input — describe the buyer task, the screens involved, and the tone. Include any existing UI captures or a URL if the agent can reference it.
• Generation — the agent writes the demo as code: HTML, copy, navigation, CTA. No re-recording.
• Review — check that the path makes sense, the copy matches current messaging, and the CTA goes somewhere real.
• Publish — host it, embed it, or drop the link into your outbound sequence.

PostHog's demo handbook recommends writing down a few bullets to structure the demo before you start. The same idea applies here. The prompt is the structure. Write it like a brief, not a feature list.

What to skip when the first version looks done

The first draft usually has too many screens, generic narration that sounds like a product tour, and at least one section that exists because someone thought it was impressive rather than useful. Cut anything that does not directly serve the buyer's task.

Generic narration, like "welcome to our platform, let's get started," is drag. Replace it with a line that names the buyer's problem in the first five seconds.

Keep your async sales demo current when the product changes

Why screenshots and screen recordings age badly

The problem is simple: the demo lives apart from the product. It is a static artifact — a recording or a set of captured screenshots — with no connection to the source of truth. Every time the UI changes, the pricing changes, or a feature gets renamed, the demo is wrong and nobody automatically knows it.

Demo automation tools that work from captures have the same problem. The automation runs on the captured state, not the live product. The demo goes stale the moment the product ships.

The maintenance loop that actually works

A refresh workflow that does not require a full re-record:

• Detect the change — a product update ships; someone on the team flags which screens or copy it affects.
• Update the source of truth — if the demo is code, update the relevant component or copy string.
• Regenerate or edit the affected step — re-prompt the agent against the changed section, or edit inline.
• Verify the published asset — check the live demo matches the current product before the next outbound batch goes out.

That is four steps, not forty. It works because the demo is close to the code, not isolated in a separate tool.

Before and after: the update the buyer would notice

Take the pricing change from the intro. In a screenshot-based demo, fixing it means recapturing every screen that shows pricing, re-recording narration if there is any, and re-publishing. In a code-owned demo, it means updating one copy string and re-prompting for the affected screen.

The buyer sees the correct pricing. The fix takes minutes, not an afternoon.

Treat the repo as the maintainer's workflow for async demos

Versioning, approvals, and rollback without drama

The demo should be versioned alongside the product. When a UI change ships, the demo update goes in the same PR or a linked one. If the update breaks something — wrong copy, broken navigation path, a CTA that points nowhere — roll back to the previous commit. No special demo tooling required.

Approval is lightweight: the founder or a designated reviewer checks the diff before merge. One person, one review, done.

How engineers and founders share ownership

Engineering owns the demo source — the code, the components, the data. Non-engineers, like founders, marketers, and RevOps, can review the rendered output and request changes in plain language. The agent translates the request into a code change. Nobody needs to rebuild from scratch, and nobody needs access to a SaaS editor they do not control.

Why repo-based ownership beats a separate demo island

When the demo lives in a separate tool, it drifts. Product ships, the demo does not move with it, and nobody notices until a prospect points it out. When the demo is in the repo, it is part of the release checklist.

Personalize the async sales demo without rebuilding it for every buyer

Role-based variants for founders, engineers, and RevOps

The same core demo path can serve three different audiences if you change the opening frame, the proof points surfaced, and the CTA. A founder cares about strategic fit and ROI. An engineer cares about how it integrates and what the maintenance burden looks like. RevOps cares about pipeline visibility and handoff.

You do not rebuild the demo for each role. You re-prompt for a variant: same flow, different opening line, different screen emphasis, different CTA copy. Personalized buyer videos that require a full rebuild per role are a time sink. Variants from a shared base are not.

The parts you personalize first

In order of impact:

• The opening line — names the buyer's role or pain directly.
• The proof point screen — shows the feature most relevant to that role.
• The CTA — matches what that buyer's next step actually is, whether that is booking a call, starting a trial, or reading the docs.

Company name and logo matter for high-intent accounts. Everything else is optional.

When personalization helps conversion and when it is just busywork

Personalization earns its keep when the buyer's path through the product is genuinely different by role or use case. It is busywork when the core demo is the same and you are just swapping a name in the header. If the demo path does not change, a personalized subject line in the email does more work than a personalized demo.

Track the demo signals that tell you whether it is moving deals forward

The engagement signals worth watching

The signals that tell you something real:

• Watch depth — did they finish, or did they drop off at screen three?
• Repeat views — a second view from the same account usually means they are sharing it internally.
• CTA clicks — did the demo produce an action, or just a view?
• Reply rate after send — the downstream signal that ties demo engagement to actual sales motion.

Views alone are noise. Watch depth and CTA clicks are signal.

What the team should do after a strong view

Set up a simple alert: when a prospect watches past 80% or clicks the CTA, the founder or sales rep gets notified and follows up within the hour. A16z's investment in Rewatch highlighted that companies like Brex use async video to house demos and track engagement across teams. The same logic applies to sales demos. The view is the buying signal; the follow-up is what converts it.

When the numbers look busy but the demo is not helping

High views, low replies, zero pipeline movement: the demo is getting watched but not doing its job. The usual cause is a demo that shows the product without guiding the buyer to a decision. Go back to the buyer task. Is the path clear? Does the CTA tell them what to do next? Views are vanity if they do not produce action.

Where Inkly comes in

The structural problem this article keeps circling is that most demo tools make the demo a static artifact inside their platform. When the product changes, you re-record. When a new customer needs a tailored version, you rebuild. The demo and the product live in different places, and every update turns into a manual synchronization task.

Inkly is built on the opposite premise: the demo is code you own, generated by your agent (Cursor, Claude, Codex), living next to your product. The three-prompt loop — prompt to create, prompt to update, prompt to produce a variant — replaces the re-record cycle. A pricing change means updating one string and re-prompting the affected screen. A new customer variant means re-prompting off the same base code with their context.

The tradeoff is real: you need a coding agent already set up. The hosted in-app agent is roadmap. But if you are already working with Cursor or Claude Code, maintaining demos as code you own fits the workflow you already have.

FAQ

Q: How do I create an async sales demo that prospects can watch on their own time?

Build around one buyer task — the question they need answered before they move forward — and keep it to five to seven screens with a clear CTA at the end. Host it as a standalone link or embed it on your landing page. The format that reduces the most friction for self-serve research is an interactive demo with a visible path and no login required.

Q: How do I keep the demo accurate when the product UI, pricing, or features change?

The maintenance loop is: detect the change, update the affected component or copy in the demo source, regenerate or edit the relevant screen, verify the published asset. If the demo is code you own rather than a screenshot recording, most updates are a prompt and a diff review — not a full re-record session.

Q: What is the simplest workflow to embed an async demo into a founder, engineer, or RevOps workflow?

One owner, one source of truth. The demo lives in the repo alongside the product. The founder or engineer owns the source; non-technical reviewers request changes in plain language and the agent implements them. The asset gets reused across outbound links, the landing page, and post-call follow-up from a single published URL.

Q: How can I use AI to generate or update the demo faster than traditional demo tools?

With a prompt-driven workflow, you describe the change — new pricing, renamed button, different CTA — and the agent updates the affected demo code. No re-recording, no clicking through a SaaS editor screen by screen. The time savings compound: the first demo takes roughly the same time either way, but every subsequent update is a prompt instead of a session.

Q: What should an async demo include so it supports conversion instead of just awareness?

A clear buyer task at the start, a path that answers the obvious pre-call questions, a proof point specific to the buyer's role, and a CTA that tells them exactly what to do next. Anything that does not serve those four jobs is a feature tour, not a sales asset.

Conclusion

The problem from the intro — a stale pricing modal quietly undermining every outbound email — is a maintenance problem, not a creation problem. The demo was fine when it shipped. It became a liability the moment the product changed and the demo did not.

Build the async sales demo so it can be updated, reused, and tracked without turning every product change into a re-recording session. This week: pick one buyer path, publish it, and wire in the refresh workflow before you make a second version. One path, one prompt, one source of truth you can actually keep current.