Should I vibe code
Automated Mac screenshots, website batches, guides, and local exports
An unattended screenshot timer is a small exfiltration device you built yourself. Aim it at a window, not the screen.
?
Their verdict, the Pro Monthly 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
Underneath the marketing, the core of this is `screencapture -x` on a timer, a folder, and ffmpeg at the end of the session, which is why the answer is go ahead. Nothing leaves the machine, nothing charges anybody, nobody else depends on it, and the worst realistic outcome is a wasted evening and four gigabytes of PNGs. What you will not reproduce in a weekend is the Mac-app scaffolding around it: the permission dance for Screen Recording and Accessibility, window-targeted capture that survives the target app being moved or resized, a click recorder that turns actions into an ordered guide with callouts, and a menu-bar UI you don't resent. The single thing worth deciding before you set an interval is aim. A timer pointed at the whole screen every ten seconds is a very effective way to end up with a folder containing your password manager mid-unlock, a customer record and somebody's private message — and the step-by-step guide you export from that folder is the same material with a nicer layout, addressed to someone else.
What actually breaks
not "if". the specific failures.
- Nothing that reaches anyone else, as long as it stays local. Every interesting failure here is about what happened to be on screen when the timer fired
- Screen Recording permission, which macOS ties to the binary — rebuild an unsigned app and the next run captures a black rectangle without telling you
- Keypress simulation, which needs Accessibility permission as well and stops being reliable the moment the target app isn't frontmost
- Disk, quietly. One capture every five seconds for a working day is roughly six thousand files, and they are lossless by default
- The generated guide, which is a shareable document containing every token in a URL bar, every customer name and every unread notification that was on screen when you clicked
- The timelapse, if you shell out to ffmpeg without pinning a pixel format — the file plays nowhere useful and you find out after a seven-hour session
- Batch website capture, which is Playwright's problem rather than yours until you point it at five hundred URLs and collect five hundred cookie banners
- Retina scaling and multi-monitor geometry, where the coordinates you saved yesterday describe a different rectangle today
Is that you?
the verdict is a default, not a law
- It runs on your machine, writes to a folder you named, and never uploads anything
- You capture a specific window or a fixed region rather than the whole desktop
- The output is for you — a timelapse, an archive of a session, a stack of frames you will cull
- You are happy to start from `screencapture`, ffmpeg and shot-scraper rather than writing a capture engine
- It runs unattended on a work machine with access to customer systems, because a timer has no idea what is on screen
- You are about to add an upload step, at which point every screenshot of everything becomes somebody else's storage and somebody else's breach
- The guides get exported and sent onward without a human looking at every frame first
- It is capturing a screen that other people are also on — a shared machine, a pair session, a call
If you build it anyway
the checklist, then the prompt that enforces it
- Default to a window or a fixed region, never the full desktop. Full-screen capture should be a flag you had to type, not the setting you inherited.
- Add a global pause hotkey and an exclusion list of apps that suspend capture when they are frontmost — password manager, banking, messages. Write that before the timer works.
- Write to one folder, named by you, with a visible file count and total size. A capture tool that hides its output in Application Support is a tool you will forget is running.
- Put an indicator somewhere unmissable while capture is active. The dangerous state is the one where you forgot it was on.
- Enforce a session budget — maximum frames, maximum megabytes, maximum duration — and stop cleanly at the limit rather than filling the disk.
- Make export a two-step review: show every frame that will go into a guide or a ZIP, with an obvious redact and drop control, before anything is written.
- Keep it offline. No accounts, no upload, no telemetry. Every number on this page stays low precisely because the files never leave the disk.
I am building a Mac tool that takes screenshots automatically on a timer and can turn a
session into a guide or a timelapse. It runs unattended on my own machine. Build in this
order and argue with me about the shortcuts.
1. Start with capture targeting, not the timer. Default to a named window or a fixed
rectangle; full-screen capture is an explicit flag with a warning in the help text.
2. Before the first automated capture works, add a global pause hotkey and an app exclusion
list that suspends capture while a listed app is frontmost. Seed it with password
managers, banking and messaging apps.
3. Show an unmissable indicator whenever capture is running. The failure mode of this tool
is forgetting that it is on.
4. Use system tooling rather than writing engines: screencapture or ScreenCaptureKit for
frames, ffmpeg for video, Playwright for website batches.
5. Check Screen Recording and Accessibility permissions at launch and fail loudly. Silently
producing black frames after a rebuild is the evening I do not want to lose.
6. Enforce a session budget — maximum frames, megabytes and wall-clock duration — and stop
cleanly at the limit with a reason.
7. Write output to one visible folder I chose, one subfolder per session, with a manifest of
timestamp, target window and size. No hidden application-support directory.
8. Export is a two-step review: before writing any PDF, ZIP or guide, show me every frame
with drop and redact controls, and state plainly that a guide carries whatever was on
screen — tokens in URLs, customer names, notifications.
9. For timelapse, pin pixel format and container explicitly and verify playback before
deleting any frames.
10. For website batches, rate-limit requests and treat a page that failed to load as an
error, not a blank frame in the output.
11. No network calls beyond website capture. No accounts, telemetry or upload. If I ask for
cloud sync, tell me it moves this build to a different verdict entirely and make me
confirm.
12. Out of scope on purpose: annotation, editing, OCR search, anything multi-user.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
You want the parts that are not a shell script: the click recorder that turns actions into an ordered guide, window targeting that survives the app moving, and a UI you can hand to a colleague. $7.99 a month or $89 once for three Macs is a fair price for the app scaffolding, and if all you actually need is a frame every thirty seconds and an ffmpeg call at the end, write the cron line instead and keep the $89.
There is barely anything to exit from, which is the point of a local tool: the output is dated folders of PNGs, MP4s and a manifest, all of which open in anything. The only piece worth keeping portable is the session config — target window, interval, exclusions — so keep it as a readable file next to the captures rather than in a preferences database. If you later decide the guide builder is worth paying for, the folders import into anything that reads images, and there is no account to close.
CLI that screenshots websites in batches from a YAML list, built on Playwright — the whole website-capture half, already done.
Mature cross-platform screenshot capture with annotation, useful as a reference for the capture and editing UI rather than for timed automation.
Questions
canivibecodeit says KINDA and you say SHIP IT. Why softer?
Because they are estimating the app and we are rating the outcome. Building Shotomatic as a polished Mac product — permissions, window targeting, a click recorder, a menu-bar UI — really is a weekend and then some. Getting the thing it does for you takes a `screencapture` call in a loop and an ffmpeg command, produces files you own, and cannot hurt anybody. On a site about consequences, that is a ship it.
If it is all local, why is data sensitivity the highest number on the card?
Because the sensitivity of the data is decided by whatever is on your screen, not by your code. Ten seconds of unlocked password manager, a support tool showing a customer's address, a Slack DM — the tool captures all of it faithfully and files it under today's date. Nothing leaves the machine, which is why every other number stays low, but the folder itself is a genuinely sensitive artefact and the guide you export from it is that folder with an audience.
What is the hardest part that isn't obvious?
Coordinates. Retina scaling, a second monitor plugged in on the right, a window the user moved between sessions — the rectangle you saved yesterday describes somewhere else today. Capturing a window by its accessibility handle rather than by screen coordinates fixes most of it, and that is where the Mac-specific work actually lives.
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.
Gradient, padding, rounded corners, export. That’s the whole product and it’s a canvas call.
Capture, annotate, copy. Every piece of this is a platform API you already have.
Screen plus camera to a file is platform APIs. The polish is where the money went.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice