The Problem Nobody Wanted to Admit
When I first built Picshots, I did what every founder does: I built an app. A nice one, too — smooth onboarding, clean UI, push notifications when new photos dropped. I was proud of it. I shipped it to the App Store and Play Store, set up a landing page, and waited for the wedding guests to pour in.
They didn't.
Here's what actually happened at the first dozen events: the host would set up their event, print the QR code cards, place them on every table — and then watch as maybe 20% of guests actually uploaded anything. The other 80%? They'd scan the QR code, see "Download PicShots on the App Store," and immediately close the tab. Some would mutter "I'll do it later" (they never did). Others would say their phone storage was full. A few just didn't want yet another app on their phone for a single evening.
I had built a product that solved a real problem — capturing the candid moments your professional photographer misses — but I'd wrapped it in a distribution model that created a bigger problem than the one I was solving.
The Funnel of Sadness
Let me walk you through the numbers, because they were brutal. At a 100-guest wedding:
100 guests see the QR code on their table
~70 actually scan it (the other 30 are talking, dancing, or their phone is in their pocket)
~50 land on the app store page
~30 start the download (the rest bail when they see it's 40MB or they need to enter their Apple ID password)
~22 open the app after installing
~18 complete onboarding and actually take a photo
Eighteen people out of a hundred. At a wedding where the couple paid for professional photography AND my service, hoping to capture the candid moments. I was losing 82% of potential contributors before they ever pressed a shutter button.
And here's the thing — this wasn't a PicShots problem. This is the universal mobile app conversion funnel. Industry data consistently shows that every additional step between intent and action kills 20-30% of your users. App store redirect, download wait, install permissions, account creation — each one is a tiny guillotine.
For a product whose entire value proposition was "guests take photos," I had built a system where most guests never got to the photo-taking part.
The Moment It Clicked
The turning point came at my cousin's wedding in Austin. I was a guest, not the founder that night. I watched the QR code cards sit on tables, watched people scan them, watched them frown at their phones, and watched them put their phones back down.
One of my aunts — the kind of person who takes 400 photos at every family gathering — scanned the code, saw the app store redirect, and said out loud: "Oh, I have to download something? Never mind."
She said it like it was the most obvious thing in the world. And she was right. Why would she download an app? She was at a wedding. She had a glass of wine in one hand and her phone in the other. She wanted to take a photo right now, not in three minutes after navigating two app stores, waiting for a download, and creating an account.
Check out how it works. Check out our create your event.That night I opened my laptop in the hotel room and started researching. Could you actually build a full camera experience in a mobile browser? Could you access the camera, capture high-quality photos, handle orientation, manage uploads — all without a native app?
The Technical Rabbit Hole
The short answer: yes, but it's not trivial.
The getUserMedia API has been around since 2015, but using it to build a camera that feels native is a different beast entirely. Here's what I had to solve:
Camera access and permissions. Browsers require HTTPS for getUserMedia, and the permission prompt is ugly. On iOS, Safari wouldn't even show the camera picker properly until iOS 14.5. I had to build a custom UI that explained why we needed camera access before triggering the browser prompt, because if a user denies it once, Safari remembers forever and you're dead in the water.
Photo quality. The default getUserMedia stream gives you a video feed, not a photo. To capture a still image at full sensor resolution, you need to use the ImageCapture API — which, as of 2023, was only supported in Chromium-based browsers. For Safari and Firefox, I had to fall back to drawing video frames onto a canvas and exporting them. The quality difference was noticeable, and I spent weeks tuning the canvas export settings to get something that didn't look like a 2007 flip phone.
Orientation hell. Mobile browsers report orientation differently than native camera apps. Photos would come in sideways, upside down, or with EXIF rotation tags that different browsers interpreted differently. I wrote and rewrote the orientation correction logic four times before it worked reliably across iOS Safari, Chrome Android, and Samsung Internet.
Upload reliability on spotty venue WiFi. Wedding venues are notorious for bad internet. I built a retry queue with exponential backoff, chunked uploads for large files, and a service worker that could hold photos offline and upload them when connectivity returned. This alone took three weeks of testing across different venue WiFi scenarios.
QR code scanning without a native app. This was the biggest unlock. The BarcodeDetector API is available in Chrome and Edge, but not Safari. For iOS users, I integrated html5-qrcode (5 million monthly npm downloads, battle-tested) as a polyfill. The combined approach meant guests could scan a QR code from within the web app to join an event — no camera app → QR scanner → browser → app flow. Just point and join.
The First Web-Only Prototype
I shipped the web-only version as an experiment. I didn't even tell most users — I just stopped redirecting new event links to the app store and pointed them at the browser experience instead.
The results were immediate and uncomfortable.
Guest upload rates jumped from ~18% to ~35% in the first week. That's nearly double, and I hadn't changed anything about the product itself — just removed the app download step.
But the feedback was mixed. Some users loved it. Others complained that the web version felt "less premium" than the app. A few Android users on older phones had camera performance issues. The web experience wasn't as polished as the native app, and it showed.
I spent the next two months in a weird limbo: running both the app and the web version, watching the web version consistently outperform the app on guest uploads, but feeling like I was maintaining two separate products. The codebase was a mess. The app had features the web version didn't. The web version had better conversion but worse reviews.
The Hard Decision
Killing the native app was not an easy call. I had spent six months building it. It had App Store reviews (good ones!). It had users who preferred it. It felt like a "real" product in a way that a web app didn't.
But the data was screaming at me. Here's what the A/B test over 200+ events showed:
MetricNative App FlowWeb-Only Flow
QR scan → first photo18%47%
Avg photos per guest3.25.8
Events with 0 guest uploads14%2%
Guest return rate (next event)8%22%
Support tickets (can't upload)12/week3/week
The web-only flow more than doubled guest photo uploads. Not 20% better, not 50% better — 2.6x better. The "zero upload" events — the nightmare scenario where a host pays for the service and gets nothing — dropped from 14% to 2%.
I killed the native app in March 2024. De-listed from both app stores. Redirected all existing app users to the web experience with a migration flow that preserved their event history. Sent an email to every host explaining the change.
You might also like our pricing. You might also find our create your event useful.I lost about 15% of my existing power users who were genuinely attached to the native app. That stung. But within six weeks, the overall upload volume had grown enough to more than compensate, and the product was simpler to maintain, simpler to onboard, and — most importantly — simpler for guests.
What I Learned (The Hard Way)
1. Your user isn't your customer. For PicShots, the customer is the host — the person paying for the event. But the user is the guest, and the guest's experience determines whether the host gets value. I had optimized the host experience (nice dashboard, easy setup) while making the guest experience worse (download this app). That was backwards.
2. Every step is a tax. I used to think "it's just an app download, everyone has apps." But at a wedding, "just an app download" means: find the App Store, search or tap the link, wait for it to load, tap Get, authenticate with Face ID or password, wait for download, find the app on your home screen, open it, create an account, grant camera permissions, and then take a photo. That's 10+ steps. The web version is: scan QR code, enter your name, take a photo. Three steps.
3. The web platform is absurdly capable now. Service workers, the Camera API, the BarcodeDetector API, IndexedDB for offline storage, the File API for uploads — you can build a genuinely native-quality camera experience in the browser. The gap between "native app" and "web app" has shrunk to the point where, for most use cases, the web wins on distribution and the native app wins on... nothing that matters for a disposable camera.
4. "Building in public" means admitting you were wrong. The hardest part of writing this isn't the technical details — it's admitting that I spent six months and a significant chunk of my savings building something that was fundamentally the wrong approach. But that's the whole point of building in public. If I only shared the wins, I'd be doing a disservice to every other founder who's currently polishing an app nobody wants to download.
5. Simplicity compounds. Removing the app didn't just improve upload rates — it simplified everything downstream. Fewer support tickets about installation issues. Faster onboarding for new events. Easier A/B testing (one codebase instead of two). Lower hosting costs (no app store review cycles, no native build pipeline). The decision to go app-free created a cascade of secondary benefits I hadn't anticipated.
The Numbers Today
As of mid-2026, PicShots processes photos from thousands of events per month. The average event sees 47% of guests contribute at least one photo — up from 18% in the native app days. The average guest takes 5-6 photos. Events with zero uploads are below 2%.
More importantly, the product feels right now. The experience matches the promise: you put a QR code on a table, guests scan it, and photos appear. No asterisks. No "download required." No friction between the moment of intent and the moment of action.
I'm not saying native apps are dead. For products that need deep OS integration, offline-first experiences, or heavy computation, native still wins. But for anything that lives at the intersection of "real-world event" and "digital participation," the app-free approach isn't just a nice-to-have — it's the difference between a product people use and a product people almost use.
If you're building something that requires other people (not just your direct users) to participate, ask yourself: how many steps are between them and the value? Every step is a tax. And taxes, as we all know, suppress activity.
Sometimes the best feature is the one you remove.
I'm building PicShots in public. Follow along at picshots.app or find me on Twitter/X where I share the messy, unpolished reality of building an event tech startup. No corporate blog posts, no PR-filtered success stories — just what actually happens when you try to build something people want.
Top comments (0)