Should I vibe code
Capture clicks and screenshots into an interactive walkthrough with editable annotations
A screenshot leaks what you saw. A DOM capture leaks what the page had loaded.
?
Their verdict, the Scale price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Scribe's entry already makes the screenshot argument: capture your app, redact what was on screen, review before you publish. Supademo raises the stakes in one specific way that is worth understanding before you build it. An interactive walkthrough is not a picture of your product, it is a copy of the page — markup, styles, and in the good implementations the DOM itself — which means the captured artefact contains everything the browser had loaded, not just what a human could see. The preloaded JSON payload. The rows below the fold. The admin-only menu that was hidden by CSS. Then the whole thing gets published to a link you email prospects and embed on a marketing page. The build is a fun weekend and the capture engine is a genuinely hard multi-month problem, so treat the weekend as the point. What you should not do is put the output in front of strangers without a step that reads the capture as text and greps it for names.
What actually breaks
not "if". the specific failures.
- The capture, which carries the whole page: the API response embedded in a script tag, the next twenty customers in the paginated list, the menu items your role could see and the prospect's could not
- Redaction, because blurring a region of an image deletes pixels but blurring a region of a DOM capture only styles it — the text is still in the file and still selectable
- The share link, which is public by default, embedded on a marketing page, indexed, and screenshotted by whoever you sent it to
- Hotspot positions, which drift the moment you re-record a step and quietly point at the wrong button
- Staleness, because nothing tells sales that the demo shows a screen the product no longer has
- Font, icon and asset loading, since a capture that references your app's CDN breaks for viewers the day that path changes
- The hosting bill, if a demo you embedded on the pricing page actually works
Is that you?
the verdict is a default, not a law
- Every capture is taken on a seeded demo tenant whose records are invented
- The output stays internal — onboarding docs, an internal wiki, a support macro
- A human reviews each captured step, as text, before anything is published
- The demo lives behind a token you can revoke rather than a public URL you cannot
- Captures come from production with real customer records on screen
- Redaction is a CSS blur over a DOM capture, which is a visual effect and not a deletion
- The finished demo is embedded publicly and nobody has read the capture file
- You would not be able to tell me, today, which demos are live and what is in them
If you build it anyway
the checklist, then the prompt that enforces it
- Capture from a seeded demo tenant with invented data. This removes the redaction problem outright rather than mitigating it, and it makes better demos because you can choose the records.
- Redact by deleting nodes and rewriting text content, never by overlaying or blurring. If the string survives in the saved file, it has shipped.
- Before publishing, extract all text from the capture and grep it for known customer names, email patterns, internal ids and anything matching a token format. Fail the publish, do not warn.
- Strip script tags, inline state and data attributes from the capture. A walkthrough needs pixels and click targets, not your app's bootstrap payload.
- Default every demo to private with a revocable token and an expiry, and keep a list of what is currently public with the date it was captured.
- Version each demo against a product version and surface anything older than a threshold as stale, because the person sending it will not notice.
- Keep the raw capture separate from the published artefact so a bad redaction can be fixed without re-recording the whole flow.
I am building an interactive product demo tool: capture a workflow in the browser, turn it into clickable steps, publish it as a link. Treat the captured file as the dangerous artefact and push back when I try to publish faster.
1. Ask me first whether captures will come from production. If yes, tell me to seed
a demo tenant with invented records instead, and explain that this deletes the
redaction problem rather than managing it.
2. Decide with me what a capture actually contains before writing the capturer. If
it saves DOM, say plainly that the file will include text no human could see:
preloaded JSON, off-screen rows, elements hidden by CSS, role-gated menus.
3. Strip on capture, not on publish: remove script tags, inline application state,
data attributes and any element hidden by display or visibility rules.
4. Implement redaction as node deletion and text replacement. Refuse to implement
redaction as a blur, an overlay or an opacity rule over a DOM capture, and tell
me why when I ask for one.
5. Build the publish gate before the editor: extract every string from the finished
capture, match it against a list of customer names, email patterns, internal id
formats and token shapes, and block the publish on a hit. Blocking, not warning.
6. Demos are private by default. Sharing mints a high-entropy token with an expiry;
there is no permanent public URL unless I ask for one explicitly, per demo.
7. Keep a dashboard of every currently public demo with its capture date and its
source tenant. I will forget what is out there; the tool must not.
8. Store the raw capture separately from the published artefact so a bad redaction
is fixable without re-recording.
9. Stamp each demo with the product version and mark it stale after a threshold I
choose. Say that the person sending a nine-month-old demo will never check.
10. Self-host the assets a capture depends on. A demo that hot-links my app's CDN
breaks silently the day that path changes.
11. Out of scope unless I ask again: AI voiceover, branching paths, lead capture
forms, and per-viewer analytics — the last one turns this into tracking and
brings consent obligations with it.
12. Finish by telling me what $50 a creator buys: a capture engine that has already
met every one of these edge cases, and somebody else's name on the incident.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Your demos go to prospects rather than colleagues. $50 per creator a month buys a capture pipeline that has already met the hidden-element problem, hosting with revocable links, and analytics you would otherwise build badly. The honest split is that internal walkthroughs on seeded data are a great weekend project, and anything embedded on a public page is not the place to find out what your capturer keeps.
$50/mo is cheaper than your weekend.
Export each demo as a folder — the ordered steps, the captured assets, the hotspot coordinates and the copy — plus a manifest of which demos are currently published and where they are embedded. That manifest is the piece that matters: an interactive demo you cannot locate is one you cannot take down, and taking it down is the only remedy available once a capture turns out to contain a real name.
Open-source screen recorder with sharing links; covers the capture-and-publish half but not the interactive steps.
Mature open-source guided-tour library; the player half of an interactive demo, over your real app rather than a capture.
Questions
How is this different from the Scribe entry?
Scribe produces images and text for documentation, and its risk is what was visible on screen. Supademo produces a navigable copy of your interface, and its risk is what was in the page. Those are different problems: you can review a screenshot by looking at it, and you cannot review a DOM capture by looking at it, because the parts that matter are the parts that were never rendered.
Is a screenshot-only capture safer?
Meaningfully, yes. Images contain only what was drawn, which means a human review is a real review and redaction genuinely removes pixels. You lose text selection, responsive layout and crisp zoom, and you gain the ability to look at the artefact and know what is in it. For a self-built version that is a good trade.
What is the one check worth building even for an internal tool?
The text grep before publish. Pull every string out of the finished capture, match it against your customer names, your email pattern and your internal id format, and refuse to publish on a hit. It takes an afternoon, it catches the failure that would otherwise be permanent, and it works regardless of how careful the person capturing was feeling.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Auto-generating step-by-step docs is capture plus OCR plus restraint.
Interactive product demos are screenshots with hotspots. That is a very reachable weekend.
Automatic cursor zoom looks like magic because getting it to feel right is genuinely hard.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice