Launching today
Mirage
Turn your SaaS into a clickable demo in 90 seconds.
176 followers
Turn your SaaS into a clickable demo in 90 seconds.
176 followers
Most product demos are a 40MB video nobody finishes or a $500/mo tool no bootstrapper can justify. Mirage is the third option: capture your real app in one click, add guided hotspots, and publish a clickable demo you can embed anywhere in ~90 seconds. Track views, completions, and per step drop-off so you fix the leak instead of guessing. Perfect for landing pages, PH launches, and onboarding emails. First demo is free forever.
Mirage
@anukarop 90 seconds is the capture, but the part that eats my team's time is editing tooltips and scrubbing customer data out of screenshots. How much of that is automated? Asking because the last tool we tried was fast to record and then two hours of cleanup per demo.
Mirage
@artem_fedorovich Great question. Cleanup is where most tools slow you down. With Mirage, you can edit tooltips and swap screenshots after capture, so fixing copy or redacting data takes minutes, not a full re-record.
@anukarop What was the single hardest UX trade-off you faced while designing Mirage’s capture flow, and how did you decide which side to favor?
Mirage
@swati_paliwal The hardest trade-off was auto-capture vs. control: record every click and you get a complete but bloated demo, or hand-pick each step and risk people abandoning halfway.
We chose capture-everything-first, then make trimming dead simple in the editor. This is way easier to delete extra steps than to realize you missed the one click that mattered.
A lot of teams know people leave somewhere during a demo, but they dont always know exactly where the interest drops. That kind of insight seems just as valuable as the demo itself.
One small idea: have you thought about adding a way to tag hotspots as "must see" versus "optional"? That could help people build shorter demos for first-time visitors while keeping deeper content available for users who want to explore more.
Mirage
@johan_nystrom Thanks! Really appreciate the suggestion. We love the "must see" vs "optional" hotspot idea and will be adding it in one of our next product updates! 🙌
Great timing for me personally — I'm mid-way through building a demo video for my own launch, and the "clickable" angle is interesting since most demo tools just produce a static walkthrough video. How are you handling the underlying app state for the clickable version — is it recording real interactions and replaying them, or simulating a fake environment? Curious how much fidelity you get without literally embedding the live app.
Mirage
@abhineetarora Second approach, Mirage takes a snapshot of each screen from your real app, then puts clickable hotspots on top. So it's more of a frozen replay than the live app running; which means no auth or data headaches, it loads instantly, and it keeps working even if your backend changes later. Fidelity stays high since it's your actual UI, not a mockup. Best of luck with your launch, you've got this!
@anukarop That makes sense — frozen replay is a smart tradeoff, you get the "it's really my product" credibility without the backend fragility of a live embed. Appreciate the detailed answer, and the good luck wish! Back to my own screen-recording grind for now, but this is a genuinely interesting approach for embedding an interactive demo on our own site down the line.
Ninety seconds to a clickable demo is impressive. The hard part is usually state isolation: capturing real product behavior without exposing live data or breaking authenticated flows. The tradeoff between intercepting API calls vs. DOM snapshotting is real, and each approach has different fidelity tradeoffs. How does Mirage handle authenticated routes? Does it replay requests or work from static snapshots?
Mirage
@anand_thakkar1 Mirage captures the rendered DOM as you navigate authenticated flows, creating static snapshots instead of replaying live requests. That means nothing connects to your backend during playback, so no live data or tokens are ever exposed. You give up real request replay, but in return you get isolated, reliable demos that continue working even as your API evolves!
the per-step drop-off tracking is the feature that actually sells me, most demo tools stop at view counts and leave you guessing which step lost people. once you see a specific hotspot is where viewers bail, can you edit or reorder that step without recapturing the whole flow, or does a change mean starting over
Mirage
@galdayan Yeah, that's exactly the part I cared about most. View counts just tell you people showed up, not where they quietly gave up. So once you see a hotspot where folks are bailing, you can just fix that one step; reword the tooltip, move the hotspot, reorder it or just swap the screenshot and republish. You just patch the spot that's leaking and move on.
Congrats on the launch! QQ - when someone re-skins a demo with an updated UI, does the choreography still hold or do the hotspots and cursor path drift off the new screenshot? Curious how much re-tuning a normal UI change costs before it feels directed again. Neat product!
Mirage
@artstavenka1 Thanks! Good question, and honest answer: hotspots are pinned to coordinates on the screenshot, so if the new UI keeps roughly the same layout, the choreography holds fine. If things moved around, the hotspot and cursor can land a little off, and you'd nudge them back into place on that step. It's a drag-and-drop fix per screen, not a rebuild, so a normal UI refresh is usually a couple minutes of re-tuning to make it feel directed again. Bigger redesigns cost more, but you're only touching the steps that actually changed.
Congrats on the launch. That 'record a video nobody watches or pay $500/mo' framing is why I've had an empty demo slot on my own landing page for weeks. Since it captures the real running app: when I publish and embed it on a public page, does the demo replay the actual captured frames, or can I repoint those same steps at placeholder data before it goes live? Mostly thinking about what I'd want to swap out before it's out in the open.
Mirage
@vollos Thank you, and that empty demo slot is exactly the itch I was scratching!
So yes, a published demo replays the actual captured frames, but those frames aren't locked. Each step is editable before you go live, so you can swap in a screenshot with placeholder or dummy data, blur or replace anything sensitive, and adjust the tooltip copy to match. Basically you capture the real running app to get the structure and flow, then clean up whatever you don't want public before you hit publish and embed. Nothing goes live that you haven't signed off on.
@anukarop Makes sense, thanks. On the swap though, when I drop a placeholder in for a step, does that replace the original capture or does the real-data frame still sit on your side? Mostly thinking about where the real stuff ends up once the public version's cleaned up.
Mirage
@vollos Good question, Actually the swap actually replaces the frame in that step, and here's the important part: drafts live locally in your browser, nothing touches our servers until you hit publish. So when you publish, only the cleaned-up version gets uploaded. The real-data frame never leaves your machine unless you choose to publish it.
@anukarop That's the answer I was hoping for. Keeping drafts local so the real frames never become your liability is the right call, and it's the line I'd put on the landing page. Good luck with the launch.