Rendemo

Hey Product Hunt. I’m Jake, and I built Rendemo.

I’ve spent close to 10 years working in customer support and technical support, and I still do it full time today. A lot of what Rendemo has turned into comes directly from dealing with the same problems over and over again.

I’ve answered the same customer question hundreds of times. I’ve sent people knowledge articles that were already outdated. I’ve written step-by-step guides that technically explained everything, but were still harder to follow than just showing someone what to click.

But that actually isn’t why I originally started Rendemo.

I was working on another product and needed to make a demo for it. I tried a bunch of the tools already out there and kept running into the same problem. The affordable ones were frustrating to use, and the good ones cost more every month than the product I was trying to demo was even making.

So I figured I’d just build my own.

At first, it really was that simple.

But while building it, I realized there was a much bigger idea here. Instead of recording screenshots, Rendemo captures the actual page and turns it into something you can keep using in different ways.

That one recording can become an interactive demo, an embed, an MP4, or even a live walkthrough that runs directly on top of the real website. I’m also building around things like CI checks so demos don’t just quietly break every time the product changes.

That’s the part I’m most excited about.

“Interactive demo tool” is technically what Rendemo is, but I think it undersells what I’m actually trying to build.

Here’s what it does:

▸ THE CAPTURE IS REAL DOM, NOT SCREENSHOTS

The Chrome extension records the actual HTML of your product as you
click through it. Not a video, not a sequence of PNGs with hotspots
drawn on top. A viewer is inside a real document: text is selectable,
your CSS is doing the layout, your fonts render.

▸ ONE RECORDING BECOMES THREE VIEWPORT BUILDS

Publishing reflows that recorded DOM to 1440x900, 768x1024 and
390x844, and your product's own media queries produce the rest. The
mobile demo is genuinely your mobile layout, not a desktop capture
scaled down. The embed then picks a build by measuring itself rather
than the screen, cutting at 547px and 1052px. Those are the geometric
means of the authored widths: distortion is a ratio, so the fair cut
is where the two candidate scale factors are equal. A 400px sidebar
on a 27 inch monitor is the same problem as a phone, and gets the
same answer.

▸ THE EMBED IS ONE SCRIPT TAG, NO BUILD STEP



It is a web component. The poster still mounts the iframe behind it
during idle time after your page paints, so in the normal case the
visitor never clicks a play button and never sees a loading state.
Five DOM events come back out: ready, step, complete, lead, close.
The lead event deliberately carries no field values. I don't want
your visitors' email addresses crossing into your analytics through
my embed.

▸ TOURS RUN ON YOUR REAL PRODUCT, ANCHORED TO YOUR REPO

The part I'm proudest of. A tour is guidance the user performs on
your live app, and each step anchors to a marker on a real element
in your source:

data-rendemo="onboarding/new-project"

You don't write those by guessing. Record yourself doing the tour and
the agent matches each click back to source through React's
_debugSource, then data-testid, id, name, href, and visible text, in
that order of confidence. When it can't place a click confidently it
returns the step as unplaced with everything it tried, rather than
anchoring to a close-enough element that would point at the wrong
thing forever.

It commits a lockfile, and then:

npx rendemo check

Zero dependencies, offline, no auth, source only. It confirms every
step resolves to exactly one marker, and exits 1 on missing-marker,
duplicate-marker or orphan-marker. Put it in CI and a UI change that
breaks a tour fails the build, instead of failing silently in front
of a customer. This repo dogfoods it on a nine step tour of the
studio itself.

The runtime is a shadow root in a fixed layer, pointer-events none
except the card. It never calls preventDefault and never stops
propagation, so your own click handlers run exactly as they would
with no tour on the page. It never steals focus. A target that isn't
in the DOM yet is waited for with a MutationObserver for 8 seconds,
then gives up visibly with a skip option rather than hanging.

▸ AN MCP SERVER ON EVERY PLAN, INCLUDING FREE

npx rendemo login signs in by browser approval and writes the MCP
registration. Claude Code can then write the step captions, apply
your brand kit, direct the camera, lint for covered targets and
clipped crops, publish, and hand back the embed snippet. One prompt,
capture to published.

▸ PRICING, AND WHY

Real HTML capture is the free plan. Unlimited demos and creators is
$39/mo flat. Elsewhere the equivalent tier starts at $150/mo and runs
past $600, and it is priced per seat, so it gets worse the moment a
second person wants to make a demo. Charging per workspace instead
was the whole point.

▸ BEING STRAIGHT WITH YOU

Rendemo is brand new. No sandbox demos. Not SOC 2. It can't tell you
which company viewed your demo. And password-protected demos can't be
embedded yet: the access cookie is SameSite=Lax, so a browser drops
it inside the third-party iframe, and fixing it needs a Partitioned
cookie on two routes. Competitors do the first three, and every /vs
page on the site says so, with a section on what they do better.

What I'd love from you: record the workflow you explain most often,
and tell me where it felt worse than doing it by hand.

Free plan, no card: rendemo.com