The event photo problem has a well-known “solution” that nobody actually likes: download an app, create an account, wait for the gallery link to land in your inbox a few days after the event is already a memory. Every step in that chain is friction, and friction at a party or a conference booth doesn’t get tolerated — it gets ignored. Guests who won’t download an app for a two-hour event still want to see and share the photos being taken of them right now.
FotoSynk’s answer is deliberately boring from the guest’s side: scan a QR code, and you’re in. No app, no account, no waiting. That simplicity on the guest’s side is exactly what makes the engineering on our side hard — every piece of friction we removed from the user is a constraint we had to absorb somewhere else in the system.
The point of improvement
Event organisers were choosing between two bad options: a dedicated app nobody wants to install for a single event, or a photographer’s gallery link that arrives days later when the moment’s already cold. Both options lose the thing that actually matters at a live event — photos and video reaching people’s phones while the event is still happening, so they get shared in the moment instead of forgotten in an inbox.
Removing that friction sounds like a design decision. In practice, it’s a systems engineering problem, because every convenience for the guest — no install, no account, instant access — removes a layer that other platforms rely on to manage reliability.
The frontend problem browsers don’t make easy
No app means the entire capture and viewing experience has to run inside a mobile browser, on a client that’s fundamentally more constrained than a native app: no guaranteed background execution, inconsistent camera APIs across iOS Safari and Android Chrome, no reliable persistent storage, and a browser tab the OS can kill the moment memory gets tight or the guest switches apps to check a text message.
We built a custom-designed JavaScript camera client specifically to work within those limits rather than pretend they don’t exist. It handles capture, local buffering, and upload orchestration as three separate concerns, so a limitation in one — say, the OS suspending the tab mid-upload — doesn’t take down the other two. Getting a smooth, native-camera-like experience out of a browser sandbox that was never designed for it is most of the actual engineering effort behind FotoSynk. The guest just sees a shutter button that works.
The connectivity problem venues don’t solve
The other major source of guest dissatisfaction has nothing to do with the software at all: venue wifi. Weddings in marquees, conferences in basement function rooms, festivals in fields — the common thread is dozens or hundreds of phones fighting over bandwidth that was never sized for it. A platform that assumes a stable connection to complete an upload is a platform that loses photos exactly when people are taking the most of them.
Our answer was to stop treating the network as something the capture flow depends on. The custom camera client performs snap, store, and queue as three distinct steps:
- Snap. The photo or video is captured and held in memory the instant the shutter fires — no network round-trip gates the capture itself.
- Store local. The capture is immediately written to local, on-device storage. At this point the media exists independently of the network, the tab’s lifecycle, or anything else that could interrupt it.
- Queue. The upload is handed to a persistent queue that retries against the network as connectivity allows — one bar, no bars, a brief drop as someone walks between access points — without the guest ever seeing an error or needing to retry anything themselves.
The result is a platform that behaves the same whether the venue has enterprise-grade wifi or none at all: guests keep capturing, media keeps getting held safely on-device, and the queue drains to the cloud whenever the network gives it the chance. Media loss under poor connectivity — the single biggest source of “the app ate my photos” complaints on every competing platform — isn’t a tradeoff FotoSynk guests have to accept.
The infrastructure behind zero degradation
Getting media safely off the phone is half the problem. The other half is what happens when hundreds of events are doing this at once, each with its own concurrent crowd of guests uploading and viewing in real time.
FotoSynk is served from a global edge network of over 330 points of presence, so a guest at an event on one side of the world isn’t routing every request back to a single origin server on the other side of it — the platform is close to wherever the event actually is. Media is backed by state-of-the-art, enterprise-grade R3 storage, built for the durability and throughput profile of thousands of concurrent photo and video writes rather than the occasional file upload. And the platform itself runs on cloud microservices rather than a monolith, so an event with an unusually large, camera-happy crowd scales the specific services under load — ingestion, transcoding, delivery — without that event’s traffic degrading anyone else’s.
The combined effect is that hundreds of concurrent events, each with thousands of concurrent guests, can capture and share media at once without the platform slowing down for any of them. It’s the same principle as the local-first camera client, applied at the infrastructure layer: don’t let one part of the system under load become every part of the system’s problem.
Why this is the same discipline we bring to client systems
FotoSynk isn’t a side project we point to as a portfolio piece — it’s the same engineering standard we hold client work to, proven on a product where we own every layer and answer for every failure ourselves. A resilient local-first client, a network that doesn’t assume good connectivity, and infrastructure that scales horizontally instead of degrading under load are the same requirements we bring to a client’s document pipeline or query layer. We just get to prove it in public, in real time, at someone’s actual wedding.