I built the Clash of the Titans team a custom CMS with an image pipeline, S3 storage, and a working upload flow. During the actual festival, they would not have used it. Not because it was bad — because of where they were standing.
The person with the photos is at the venue, on their phone, between screenings. The gap between "I have twelve good photos" and "they are on the website" has to be about ten seconds long, or it doesn't happen until next week, which for a five-day festival means never.
Meeting the workflow that already exists
Here's the thing about event teams: they already have a shared Google Drive folder. Everyone on the team already dumps photos into it. That habit exists whether or not I build anything, and it existed before the website did.
So the integration wasn't "add photo uploads to the CMS." It was: make the folder they already use the source of truth. Organizers drop photos into the shared Drive folder, and they show up in the homepage gallery. No CMS login, no upload step, no training.
The feature is essentially an admission that the best interface was one I hadn't built and couldn't improve on.
Why this is better than it sounds
It's tempting to read "we sync from Drive" as a shortcut, or as ducking the real work. I'd argue the opposite — it removes several problems that an upload form creates and then has to solve:
- No permissions design. Whoever can already put files in the team folder can already publish. The access model is the one the team has been running for years, and it's one fewer system for someone to be locked out of at the worst moment.
- No training. There is nothing to teach. The instruction is "same folder as always."
- No mobile upload UI. Building a genuinely good mobile multi-file uploader is real work. The Drive app is already that, and it already handles flaky venue wifi, backgrounded uploads, and retries.
- Bulk by default. Fifty photos is a drag-and-drop, not fifty interactions with a form.
The honest trade-offs
This is not the right answer everywhere, and the constraints are real. Sync means the site's content depends on an external service staying reachable and on someone not reorganising the folder. Ordering and curation are weaker than an explicit gallery editor would give you — a folder has no opinion about what should lead.
There's also a deletion hazard worth naming: if the folder is the source of truth, then someone tidying up the folder is editing the live site, possibly without realising it. That's an acceptable risk for event photos and a completely unacceptable one for, say, legal documents.
The CMS upload path still exists for everything that needs deliberate curation. Drive sync is specifically for the high-volume, low-stakes, time-critical case — which happens to be exactly the case that occurs while the event is running and everyone is busiest.
The general lesson
The reflex when a client says "we need to be able to add photos" is to build the photo-adding feature. Sometimes the better move is to find the tool they're already using at that moment and wire into it.
This applies well beyond galleries. Before building an interface, it's worth asking what the client will actually have open when they need it — and whether the honest answer is a spreadsheet, an inbox, or a phone camera roll.
The gallery sync shipped as part of a two-week rebuild that also included a timezone-correct live countdown and a self-generating admin CMS. Of those three, the one the organizers mention is the folder.
This post draws on a real build. Read the Clash of the Titans case study →
Related. what a full revamp includes →