Should I vibe code
Catalog local and network photos with duplicates, tags, and device-aware storage
Every other program you write can be reinstalled. Your photo library is the only file set with no upstream copy.
?
Their verdict, the Individual 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
Walking a folder tree, hashing for duplicates and reading EXIF is a satisfying evening, and the result genuinely can beat a paid catalogue for your particular mess. Mylio's real product is the part you would build fourth: a sync model that decides which device holds the original and which holds a proxy, so a phone can browse a hundred thousand photographs it does not contain. That is a distributed-systems problem wearing a photo app's clothes, and its failure mode is not a crash you notice. It is a delete that propagates, or a dedupe pass that keeps the wrong file. This is the one library in your house with no upstream copy — nobody can reissue your father's slides, and the backup you trust is a mirror of whatever your code did last night. The verdict here is not about difficulty. It is about what the mistake costs.
What actually breaks
not "if". the specific failures.
- Deduplication, which decides a 2048px export and the RAW it came from are the same photograph, and keeps whichever one your comparison happened to prefer
- Sync, where a delete on one device is a delete everywhere, including on the device that held the only original
- Space-saving proxies, which look exactly like the photograph right up until the machine holding the full-resolution file is the one that died
- Metadata writes, if the tool edits EXIF in place rather than beside the file — one bad batch and every capture date in the library has shifted
- The catalogue database, which is the only place your albums, ratings, people and stacks exist, and which has no backup discipline of its own
- Face grouping, which is fine until it merges two siblings and you "fix" it with a bulk rename across three thousand tags
- HEIC, live photos, RAW+JPEG pairs and video sidecars, each a file group your importer will happily treat as unrelated files
- Ninety thousand files, where the thumbnailer that took four minutes on your test folder now takes eleven hours and does not resume
The importer ran overnight against the NAS with the dedupe pass enabled for the first time. It scored pairs by pixel similarity and kept the larger file wherever the hashes disagreed — correct everywhere except the 4,100 scans of your parents' negatives, where the larger file was an upscaled JPEG some previous tool had produced and the original TIFF was the smaller one. The delete was real, on the NAS, which mirrors to the backup drive nightly, and the mirror completed at 02:00. The scanning took two summers. There is no other copy, because the negatives went into a skip during a house move in 2011.
Is that you?
the verdict is a default, not a law
- It reads and never writes: index, hash, tag in sidecars, report duplicates, delete nothing
- Every original is already covered by a backup you did not write and have restored from at least once
- The catalogue is derived data you can throw away and rebuild from the files themselves
- It runs on one machine, and sync is somebody else's product
- The tool can delete files and those deletes propagate anywhere
- The only copy of anything lives on a device your code manages
- It rewrites EXIF in place instead of writing sidecars beside the originals
- The app's own database is where your albums, ratings and people are remembered
If you build it anyway
the checklist, then the prompt that enforces it
- Delete nothing, ever. Move to a quarantine directory with a manifest and a restore script, and let a human empty it after a week. Every catastrophic story in this category is a delete that seemed obviously correct.
- Verify the backup before the first write, by restoring a real file from it. A library protected by an untested backup is a library protected by a feeling.
- Never decide what to keep from visual similarity. Prefer more bytes, more EXIF, a RAW extension and an earlier mtime — and when those signals disagree, keep both and ask.
- Write metadata to XMP sidecars, not into the original file. In-place EXIF edits are the one operation that damages the artefact you are trying to protect.
- Treat the catalogue as a cache: everything in it must be rebuildable from the files plus sidecars in one command, because one day it will be corrupt and that command is your recovery.
- Keep proxies and originals distinguishable in the filesystem, not just in the database. The day the database is wrong you need to tell a 400KB stand-in from the real thing by looking.
- Run every destructive operation as a dry run that writes a report, and make that report the only way to authorise the real run.
I am building a photo catalogue over folders on my disk and NAS: indexing, duplicates, tags, faces, and eventually sync between devices. Treat the files as irreplaceable and refuse anything that risks them, even when I ask.
1. Establish before writing any code that this tool never deletes. Destructive operations
move files to a quarantine directory with a manifest and a restore script.
2. Ask me whether my originals are backed up, and whether I have ever restored from that
backup. If either answer is no, say so and stop before the first write.
3. Build the read-only indexer first: walk, hash, read EXIF, store. No writes to any original
file anywhere in this phase.
4. Write metadata to XMP sidecars beside the originals. Refuse to modify EXIF in place, and
explain that an in-place batch is how a whole library's capture dates get corrupted.
5. Group RAW+JPEG pairs, live photos and video sidecars into one asset before deduplication
sees them, or the deduper will treat companion files as duplicates.
6. Never decide what to keep from visual similarity. Rank by RAW extension, byte size, EXIF
completeness and earliest mtime; when the signals conflict, keep both and ask me.
7. Every destructive operation runs as a dry run that writes a report. The real run takes
that report as input. There is no one-step version.
8. Make the catalogue a rebuildable cache: one command reconstructs it entirely from files
plus sidecars. Tell me the command and make me run it once before I trust the app.
9. Checkpoint long imports so a crash at file 60,000 resumes rather than restarts, and never
promote a partially written index to the live one.
10. If I ask for multi-device sync, stop and tell me this is a different and much harder
project whose signature failure is a delete reaching the device holding the only original.
11. Proxies and originals must be distinguishable on disk, not only in the database, so I can
tell a stand-in from the real file when the database is wrong.
12. Out of scope unless I ask again: cloud upload, sharing links, and anything that removes
files to save space.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 multi-device half. $25 a month, or $240 a year, buys a sync model that has been beaten on by a lot of libraries — which device holds the original, which holds a proxy, what happens when two devices disagree — plus face recognition that works and an importer that already knows what a live photo is. For a single machine, Immich or PhotoPrism self-hosted is free, actively developed, and safer than anything you will generate this weekend.
$25/mo is cheaper than your weekend.
Dated folder hierarchy, original filenames, XMP sidecars beside each file. Everything else — catalogue, thumbnails, face clusters, embeddings — is derived and should be reconstructible in a single command. Get that right and the library survives you losing interest, changing tools or changing operating systems, because it is just files. Get it wrong and your exit is a proprietary database holding your albums and a folder of DSC_ filenames with no dates.
Active open-source self-hosted photo and video management platform with mobile apps and background backup.
Self-hosted photo library with local AI tagging and face recognition that indexes an existing folder tree in place.
Fast duplicate and similar-image finder; the sane way to get the dedupe half without writing the comparison yourself.
Questions
Nothing here leaves my house. Why is this not SHIP IT?
Because the verdict tracks what the mistake costs, not who can see it. A local-only tool holding delete permission over the one file set nobody can reissue is a bigger deal than a public app that only loses rows. The score sits on the low side of its band precisely because everything stays at home; the verdict sits above the score because the failure is permanent.
Where does the danger actually concentrate?
Two places. Deduplication, because it is the one feature that decides which file to remove and it makes that decision from heuristics you will never test on the awkward cases. And sync, because it turns a single bad local decision into a decision on every device, usually shortly before the nightly mirror runs. Everything else in a photo catalogue is read-only and pleasant.
Is face recognition on my own family a legal problem?
For a purely personal library on your own machines, the household exemption keeps this out of the GDPR's way, and that is the normal case. It stops being the normal case the moment you host it for other people, publish galleries, or use it in anything commercial — Illinois' BIPA and similar US state laws attach to biometric identifiers in commercial contexts and carry a private right of action. Keep it personal and keep it local.
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.
You are not delivering photographs. You are promising a URL still resolves on their tenth anniversary.
The password gates the page. The JPEGs sit on a public bucket path, and Google does not need the password.
A gallery that sells prints is a shop with a factory attached. The bad crop ships, and it ships to her mother.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice