Should I vibe code
Visual bookmark manager for saving, tagging, and searching links
Save a URL, tag it, search it. This has been a solved weekend since 2004.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Bookmarks are the friendliest CRUD there is. Add full-text search over saved pages and the homemade one is arguably better than what you were paying for.
What actually breaks
not "if". the specific failures.
- Preview images and metadata, which is the visual part and means fetching every saved page
- Fetching those pages from your server, which is a request to an arbitrary URL a user supplied
- Thumbnail storage, which grows quietly and is the only part of a bookmark manager with real bytes
- Sites that block or misreport metadata, so the wall of cards has holes in it
- Cross-device access, since a visual bookmark manager is used on a phone and a laptop
The failure worth naming is not dramatic but it is a real mistake: your server fetches every URL a user saves, to get the preview image. Someone saves a link pointing at an internal address — a metadata endpoint, a service on localhost — and your fetcher, sitting inside your network, dutifully requests it and stores the response as a preview. Nothing was attacked. You built a feature that makes requests on someone else's behalf and did not restrict where they could point.
Is that you?
the verdict is a default, not a law
- Metadata is fetched client-side, or server-side with a strict URL allowlist
- Thumbnails are size-capped and have a retention policy
- It is your own collection and previews are a convenience
- Your server fetches arbitrary user-supplied URLs with no restrictions
- Thumbnails are stored at full size with no cap
- Other people can save links that your infrastructure then fetches
- There is no export
If you build it anyway
the checklist, then the prompt that enforces it
- If the server fetches URLs, block private address ranges, link-local addresses and redirects into them. This is the one real security consideration in an otherwise harmless project.
- Cap fetch size, set a timeout, and never follow more than a couple of redirects.
- Resize and re-encode thumbnails on save with a hard dimension cap — this is the only part of the app with meaningful storage.
- Degrade gracefully when metadata is missing. A card with no image should look deliberate, not broken.
- Never execute or render fetched HTML; extract the fields you need and discard the rest.
- Keep bookmarks in a simple exportable table — the collection is the asset and it should be trivially portable.
Before you build a visual bookmark manager, apply these and push back if I ask you to break them. 1. If the server fetches saved URLs for previews, treat that as a request made on a user's behalf from inside my network. Block private and link-local address ranges, resolve DNS before connecting and check the resolved address, and re-check after every redirect. Tell me this is the one genuine security consideration in an otherwise harmless project. 2. Cap the fetch: a size limit, a short timeout, and at most two redirects. 3. Consider fetching metadata client-side instead, which removes the problem entirely at the cost of some reliability. 4. Resize and re-encode every thumbnail on save with a hard maximum dimension. This is the only part of the application with real storage growth. 5. Never render or execute fetched HTML. Parse out title, description and image URL, and discard everything else. 6. Escape all fetched text before displaying it — page titles are attacker-controlled. 7. Handle missing metadata gracefully so a card without an image looks intentional rather than broken. 8. Set a retention policy for thumbnails and make export include bookmarks, tags and notes. 9. Out of scope unless I ask: sharing collections, collaboration, full-page archiving, browser sync, recommendations.
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
$3 a month is small and buys apps on every platform. Build it because the whole thing is genuinely a weekend, as the hot take says — just remember that the preview fetcher is the one part that deserves five minutes of care.
Export bookmarks, tags and notes as a simple file — thumbnails are regenerable and not worth preserving. Browsers and every competitor import standard bookmark formats, so a collection kept in one of those is never trapped.
Open-source bookmark manager with archiving, collections, and collaborative saving.
Questions
Why is fetching a URL server-side a concern at all?
Because your server sits somewhere a browser does not — inside your network, next to internal services and cloud metadata endpoints. A fetcher that follows any URL a user supplies can be pointed at those, and it will faithfully retrieve and store whatever comes back. Blocking private address ranges, including after redirects, is a few lines and closes it.
How is this different from the Pinboard entry?
Pinboard's entry is about link rot and archiving text — solving the problem that URLs expire. This one is visual: previews and thumbnails, which means fetching pages and storing images, which introduces both the storage growth and the server-side fetch consideration that a text archive avoids.
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-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice