Should I vibe code
Host client galleries with favorites, downloads, and simple proofing
You are not delivering photographs. You are promising a URL still resolves on their tenth anniversary.
?
Their verdict, the Beginner 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
A grid of images behind a link is an evening's work, and canivibecodeit is right that the mechanics are within reach. The thing you have taken on is not a grid, though — it is a delivery obligation with no stated end date. Clients treat the gallery as where the photographs live, forward it to everyone who was at the wedding, and come back for the files at an anniversary, a christening, or a funeral, on a timescale measured in years rather than sprints. Meanwhile the proofing selections your client makes are the record of what they chose for the album, the full-resolution zip is fourteen gigabytes that a phone will never finish downloading, and the storage bill grows with every job while the fee for each job arrived exactly once. None of it is difficult. All of it is somebody else's irreplaceable day sitting on infrastructure you configured one Sunday.
What actually breaks
not "if". the specific failures.
- The gallery link, which the couple forwards to ninety guests in one evening and then looks for again in 2033
- The full-resolution download, which is fourteen gigabytes, which your server rebuilds from scratch on every retry, and which no phone browser will ever finish
- Favourites and album proofing selections — the record of what the client actually chose — stored with no timestamp, no version and no way to prove what the list looked like in March
- Storage cost, which grows with every job and never shrinks, charged against a fee that arrived once
- EXIF, which quietly ships the GPS coordinates of a private house to every guest who downloads a file
- A cleanup job written when the bill got scary, deleting galleries by a rule that made sense to you and to nobody who paid you
- Image processing, the first time somebody uploads eight hundred 50-megapixel files and your single worker falls over halfway through
The storage bill crosses a hundred a month in the second year, so you write the obvious cleanup job: any gallery with no views in a hundred and eighty days gets its originals dropped and its web-size renditions kept. It runs quietly, it works, the bill halves, and you forget about it entirely. Fourteen months later a client emails — the laptop with the wedding folder died, the external drive that was supposed to be the backup was the laptop's Time Machine disk, and could they please re-download the full-resolution files. They are polite about it, which is worse. You go and look, and what you find is the rendition set: eleven hundred images at 2048 pixels on the long edge, watermark-free and lovely on a phone, and completely useless for the album her mother wanted printing. There is no version of this conversation where the cleanup job was a reasonable decision, and you made it alone, in an afternoon, with no policy written down anywhere the client could have read.
Is that you?
the verdict is a default, not a law
- It is your own work, delivered to a handful of clients you can phone, and the originals live somewhere else that is properly backed up
- The gallery is a copy of the delivery, never the delivery itself — every client also gets files by another route
- You have written down how long galleries stay up, it is on the invoice, and the deletion job honours exactly that and nothing more
- Downloads are served from object storage through signed URLs, not streamed through your app server
- Your gallery is the only remaining copy of anyone's photographs, including yours
- Album selections made in the tool will be treated as what the client agreed to, and you cannot reproduce that list as it stood on a given date
- There is no retention policy, so "how long will these be online" has no answer but a shrug
- You are hosting other photographers' galleries, because then a bad deploy takes out several businesses at once
- Nobody has priced the egress on a fourteen-gigabyte download that ninety guests might each start twice
If you build it anyway
the checklist, then the prompt that enforces it
- The gallery is never the archive. Originals live in a backed-up store you can restore from, and you have actually restored from it once.
- Write a retention policy before the first gallery goes up, put it in front of the client, and make the deletion job read that policy rather than your mood about the bill.
- Strip EXIF from anything a guest can download by default, and make retaining it a per-gallery choice a human takes deliberately.
- Serve images and archives from object storage via short-lived signed URLs. Never proxy a fourteen-gigabyte zip through your web process.
- Build the zip once, asynchronously, cache it, and make the download resumable. A restart on a hotel connection should not mean starting again.
- Store favourites and proofing selections as an append-only log with timestamps, and give the client an emailed confirmation of exactly what they selected. That email is the record, not your table.
- Cap and alert on storage and egress before the first upload, and know the cost of one gallery being popular.
- Generate renditions in a queue with a worker you can restart, not in the request that handled the upload.
I am building client photo galleries for my own photography business. The files
are other people's irreplaceable days and the link has to keep working for
years. Build accordingly and argue with me when I try to cut corners.
1. First, tell me what I am promising: a URL that resolves years from now, and
a copy of files somebody cannot get back any other way.
2. Refuse to treat this system as the archive. Originals live in a separate
backed-up store; this app holds a copy. Make me say where the other copy is
before you write the uploader.
3. Build deletion and retention before display. There is a written retention
policy, the job reads it, nothing is ever deleted by a rule that only exists
in code, and destructive operations are soft deletes with a recovery window.
4. Then downloads. Archives are built once, asynchronously, cached, served from
object storage through short-lived signed URLs, and resumable. Never stream a
multi-gigabyte zip through the application process.
5. Strip EXIF by default on anything a guest can download, and explain to me
that GPS coordinates in a wedding photo point at somebody's house.
6. Store client favourites and album selections as an append-only log with
timestamps, and email the client a copy of the selection when they submit it.
Assume this list will be disputed a year later.
7. Generate thumbnails and renditions in a queue with retries and idempotency,
not inline in the upload request. Assume eight hundred 50-megapixel files at
once.
8. Put a hard cap and an alert on storage and egress before the first upload,
and tell me the cost of one gallery being downloaded ninety times.
9. Share links are random, revocable and expiring by default, and revocation
takes effect on the next request.
10. Out of scope deliberately: the print store, lab fulfilment and sales
automations. Taking money for prints is a different and larger problem.
11. Finish by telling me what Pic-Time costs and being honest that for one
photographer it is cheaper than the storage bill alone.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
As soon as the galleries are for paying clients rather than yourself. At $8 a month for the entry tier and $25 for the one you will actually need, the subscription costs less than the storage it replaces, and what it really buys is that the link still works in a decade — which is a promise a company can make and a side project genuinely cannot.
$8/mo is cheaper than your weekend.
Keep the photographs in a bucket you own, organised by client and date in folders a human can read without your database, so the worst case is handing somebody an S3 prefix. What does not survive a migration is the layer on top — favourites, selections, gallery settings and view history — so export those per gallery as JSON on a schedule, and email selection confirmations at the time so the client holds a copy independent of you. The test: if the app disappeared tomorrow, could you deliver every active client's files this week using nothing but a file browser?
Active open-source self-hosted photo and video management platform.
Long-running open-source photo gallery with albums, per-album permissions and public links. Closer to client delivery than a personal library is.
Questions
Why is this harsher than the Pixieset entry when they do the same thing?
They fail differently. Pixieset's entry is about the share link and the password — how private galleries get out. This one is about time: proofing selections that become the record of what was agreed, a storage bill that grows forever against a one-off fee, and the client who comes back in year six. Both are YOUR FUNERAL, but you will meet them at different points.
Can I not just use signed S3 URLs and a static site generator?
For your own work and three clients, that is genuinely the good version, and it is close to the SHIP IT case above. It stops being enough at the point where clients make selections you will be held to, guests download from phones on bad connections, and somebody expects the link to work after you have lost interest in the project.
What is the one thing an agent will build badly without being told?
The download. It will stream a zip out of the web process, built on the fly, with no caching and no range support, and it will work perfectly on your laptop with a test gallery of forty images. It falls apart on a real wedding at fourteen gigabytes, and it fails in the way that costs you most: silently, on the client's phone, halfway through.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
Every other program you write can be reinstalled. Your photo library is the only file set with no upstream copy.
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