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

Rendemo

Turn any web app into a clickable demo in minutes

Turn any web app into a clickable demo in minutes