Should I vibe code
Capture a workflow and generate a concise step guide with screenshots and annotations
Automatic redaction is an enterprise line item. That's the price list telling you which half of this is hard.
?
Their verdict, the Pro (Team, 3+ users) 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
The capture loop is genuinely a sitting: hook click events in a content script, grab a screenshot on each one, read the accessible name of the element you hit, and write "Click Save" underneath the picture. It works on the first try and it feels like magic, which is the trap. Everything difficult about this product is downstream of the fact that the screenshots are of your real screen, taken by software rather than by a person deciding what to photograph. The URL bar is in the frame, and URLs hold reset tokens, signed links, session ids and account numbers. So is the customer record you happened to be looking at, the Slack notification that slid in at step four, and the autofill dropdown that opened over the form. Tango's own price list is the clearest evidence of where the work is: blurring is a paid feature and automatic PII detection sits behind the Enterprise call. Redaction is not a nice-to-have on top of a capture tool — it is the product, and your weekend version does not have one. Build it for yourself, on a seeded test account, and keep the output inside the building.
What actually breaks
not "if". the specific failures.
- Redaction, which is the whole job rather than a feature on top of it. Yours is whatever you remembered to blur at five o'clock on a Friday
- The address bar, present in every frame. Password-reset links, signed download URLs, session ids in query strings and internal account numbers all live there and are photographed by default
- PDF export, where a black rectangle drawn over text is a black rectangle drawn over text. The string is still in the file, still selectable, still in the copy buffer
- Blur implemented as a CSS filter or an overlay layer — the same failure wearing a different file extension
- Everything at the edges of the capture: a notification banner, a tooltip, an autofill dropdown, a second monitor's worth of tabs in the browser chrome
- The share link, because that is how these documents travel — pasted into a ticket, forwarded to a vendor, embedded in a help centre and then crawled
- Staleness. The guide shows a screen the product replaced in March, and the person following it will trust the screenshot over the interface actually in front of them
- The extension's permission grant, which for this to work is read-and-change-all-your-data-on-all-websites: the strongest thing a browser has to give
Is that you?
the verdict is a default, not a law
- Every capture is taken in a seeded test account whose customers are invented
- The guides stay internal — an onboarding doc, a support macro, a runbook nobody outside the company reads
- A human opens each finished guide and looks at every screenshot, including the address bar, before it is shared
- The output is a folder of images and Markdown you can grep, rather than a hosted link with an id in it
- Captures come from production while real customer records are on screen
- Redaction is a blur applied at display time rather than pixels destroyed in the stored file
- The guides go to customers or get embedded in a public help centre, where taking one down is a request rather than an action
- You could not tell me today which guides exist, who they were sent to, and what was on screen when they were made
If you build it anyway
the checklist, then the prompt that enforces it
- Capture from a seeded demo account. This removes the redaction problem instead of managing it, and the guides come out better because you get to choose what the records say.
- Destroy pixels, never hide them. Redaction rewrites the stored image; if the original bytes survive anywhere in the artefact, the redaction has not happened.
- Crop or mask the address bar by default and make showing it an explicit choice per step. It is the single highest-yield source of secrets in a screenshot and nobody ever means to include it.
- Run OCR over every finished capture and match the text against customer names, email patterns, internal id formats and token shapes. Block the export on a hit rather than warning about it — an open-source detector like Presidio will do this better than a regex you wrote on Sunday.
- In PDF and HTML exports, redact before the text layer is written. A drawn rectangle is a graphic; the string beneath it still copies out.
- Suppress notifications, close other tabs and use a clean browser profile for capture. Most leaks in this category arrive at the edge of the frame rather than in the middle of it.
- Stamp each guide with a capture date and a product version, and surface anything past a threshold as stale. The person forwarding a nine-month-old guide will not check.
- Keep the raw capture separate from the published artefact, so a redaction you got wrong can be fixed without re-recording the entire flow.
I am building a browser extension that captures a workflow — a screenshot and a step
description per click — and assembles it into a shareable guide. Treat the screenshots as
the dangerous artefact and slow me down where it matters.
1. First question, before any code: will captures come from production? If I say yes, tell
me to seed a test account with invented records instead, and explain that this deletes
the redaction problem rather than managing it.
2. Build the redaction pipeline before the capture UI. Redaction means writing new pixels
over the stored image and discarding the original region. Refuse to implement it as a
CSS blur, an overlay div or an opacity rule, and tell me why when I ask.
3. Mask the browser address bar by default in every capture. Make revealing it a per-step
decision. URLs carry reset tokens, signed links, session ids and account numbers.
4. Add an OCR pass over each finished capture and match the extracted text against customer
names, email patterns, internal id formats and anything token-shaped. Block the export on
a hit. Blocking, not warning.
5. For PDF and HTML export, remove the text before the file is written. Say out loud that a
black rectangle drawn over a PDF leaves the string selectable underneath.
6. Strip capture metadata: window titles, file paths, the user's display name, EXIF. These
ride along invisibly and end up in the exported bundle.
7. Only then build the capture loop, and start it in a clean browser profile with
notifications suppressed. Most of what leaks arrives at the edge of the frame.
8. Guides are private by default. Sharing mints a revocable token with an expiry; there is
no permanent public URL unless I ask for one per guide, explicitly.
9. Keep the raw capture separate from the published guide, and maintain a list of every
guide that exists, when it was captured and where it was sent. I will forget.
10. Ask for the narrowest host permissions that work, and tell me plainly what I am granting
if the answer is all URLs.
11. Out of scope unless I ask again: video, voice-over, in-app guided tours and viewer
analytics — the last turns documentation into tracking.
12. Finish by telling me what $20 a seat buys: a blurring pipeline that has already met these
edge cases, and — one tier up — the automatic PII detection I am proposing to skip.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
The guides leave the building. Twenty dollars a seat buys the annotation and blurring pipeline, hosting with links you can revoke, and version history for the day a guide is wrong; the tier above it buys automatic PII detection, which is the vendor pricing exactly the thing your homemade version will not have. Internal runbooks captured on a test account are a genuinely good weekend project and you should do it. Customer-facing documentation generated automatically from production screens is not a weekend project — it is a redaction product with a documentation feature attached.
$20/mo is cheaper than your weekend.
The output format is the exit, so choose it on day one: one folder per guide containing numbered PNGs and a Markdown file, with the step text as plain prose and the image references relative. That folder opens in any editor, imports into any wiki, and survives your project being abandoned. The piece to keep alongside it is a manifest — every guide, when it was captured, from which account and where it was sent — because a guide you cannot locate is a guide you cannot take down, and taking it down is the only remedy available once a screenshot turns out to contain a real customer's name.
Actively developed PII detection and de-identification framework whose image redactor handles the hard half of this properly.
Open-source screen recorder with self-hostable share links; the capture-and-publish plumbing, without the step extraction.
Questions
How is this different from the Scribe and Supademo entries?
Same family, three different hazards. Scribe's is what a person could see on screen. Supademo's is what the page had loaded but never rendered, because a DOM capture keeps text no human ever saw. Tango's is that the capture is triggered by your clicks rather than by your judgement — nobody framed the shot, so whatever the browser was showing at that instant is in the file, address bar included.
Is blurring in the exported PDF good enough?
Only if the blur happened to the pixels. If your exporter draws a rectangle or applies a filter over a text layer, the underlying string is still in the document and comes straight out with a select-and-copy. This is the most repeated redaction failure in public record and it is not a hard one to avoid — you just have to redact before the text is written, not after.
What is the one thing worth building even for an internal tool?
Automatic masking of the address bar. It costs an afternoon, it needs no machine learning, and it removes the category of leak that nobody intends and nobody notices: the signed URL, the reset token, the customer id sitting in a query string in every single screenshot of the flow.
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.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice