DEV Community: ArtiDigital

How I Built a No-App Photo Sharing Platform Using Just QR Codes and Browser Cameras

ArtiDigital — Tue, 11 Aug 2026 21:06:12 +0000

Last summer, I was at my cousin's wedding. 200 guests, one professional photographer, and exactly zero way for anyone else to share the photos they were taking on their phones. The bride spent weeks chasing people through WhatsApp groups and Facebook messages, trying to collect the candid shots everyone promised to send. She got maybe 30 photos out of what must have been thousands taken that night.

That moment stuck with me. I'm a developer, and I kept thinking: there has to be a better way. Not another app to download. Not another account to create. Something so simple that even your tech-averse uncle could use it after his third glass of wine.

So I built Picshots — a no-app photo sharing platform that works entirely through QR codes and browser cameras. No downloads, no sign-ups, no "check your email for a verification code." Just scan, snap, and the photos land in a shared gallery. Here's exactly how I built it, what I learned, and the technical decisions that made it work.

The Core Problem: Friction Kills Participation

Here's a stat that shaped every decision I made: for every additional step between a guest and their first photo upload, you lose roughly 40% of potential participants. I didn't pull that from a research paper — I tested it. I built a prototype that required guests to enter their name before taking a photo. Then I removed the name field. The difference? A 3x increase in photos captured.

The math is brutal:

App Store → find app → download → install → open → create account → verify email → find event → take photo = ~5% participation
Scan QR → camera opens → take photo → done = ~90% participation That 85% gap is the difference between a dead gallery and one with 500+ photos by the end of the night. The no-download approach isn't a nice-to-have — it's the entire product.

The Tech Stack: What Powers a Browser-Based Photo Platform

Before diving into the code, here's the stack I landed on after several iterations:

LayerTechnologyWhy

Camera AccessMediaDevices.getUserMedia()Works in every modern browser, no polyfills needed

QR Generationqrcode (npm, 82M monthly downloads)Battle-tested, supports SVG output for crisp printing

QR Scanninghtml5-qrcode (npm, 5M monthly downloads)Pure JS, no WASM, works on mobile browsers

Image UploadPresigned S3 URLsBypasses server bottlenecks on large files

Real-time GallerySupabase RealtimeWebSocket-based, no polling, scales to thousands of concurrent viewers

FrontendNext.js + TailwindSSR for SEO pages, CSR for the camera experience

HostingVercel + S3 + SupabaseEdge functions for QR redirects, S3 for photos, Supabase for metadata

Let me walk through each piece and the decisions behind them.

Step 1: Accessing the Camera Without an App

The getUserMedia API is the unsung hero of this entire project. It's been available in browsers since 2015, but most people don't realize how capable it is. Here's the core camera initialization code:

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: 'environment', // Use back camera on mobile
    width: { ideal: 1920 },
    height: { ideal: 1080 }
  },
  audio: false
});

const video = document.getElementById('camera-preview');
video.srcObject = stream;
await video.play();

Three things I learned the hard way:

HTTPS is non-negotiable. getUserMedia only works on localhost or HTTPS. If you're testing on a device over your local network, you need a self-signed cert or a tunnel like ngrok. I wasted an afternoon debugging this before remembering it's a browser security requirement.
iOS Safari has quirks. On iOS, getUserMedia must be triggered by a user gesture (tap/click). You can't auto-open the camera on page load. I added a prominent "Open Camera" button that's impossible to miss, and the tap satisfies Safari's requirement.
The facingMode: 'environment' constraint is a suggestion, not a command. Some Android browsers ignore it and default to the front camera. I added a camera toggle button as a fallback — it's saved me from countless "why am I looking at my own face?" support messages.

Why WebRTC Matters for Browser Camera Access

While getUserMedia handles camera access, WebRTC (Web Real-Time Communication) is the underlying framework that makes the entire browser-based media pipeline possible. WebRTC provides three core APIs that power the no-app camera experience:

getUserMedia — accesses the camera and microphone (this is part of the WebRTC spec)
RTCPeerConnection — enables peer-to-peer audio/video/data transfer
RTCDataChannel — allows arbitrary data transfer between peers Even though Picshots uses a client-server upload model for photos, WebRTC's getUserMedia is the foundation. The media constraints API (width, height, facingMode, frameRate) that I use to configure the camera are all part of the WebRTC specification. Without WebRTC standardizing these APIs across browsers, we'd be back to Flash plugins and ActiveX controls — the dark ages of web media.

I also explored using WebRTC data channels for peer-to-peer photo sharing between guests on the same venue WiFi, which would bypass the server entirely for local transfers. The RTCDataChannel API supports reliable, ordered data delivery — perfect for file transfers. I prototyped this:

// WebRTC P2P photo transfer prototype
const peerConnection = new RTCPeerConnection(config);
const dataChannel = peerConnection.createDataChannel('photos', {
  ordered: true,
  maxRetransmits: 3
});

dataChannel.onopen = () => {
  // Send photo blob directly to another guest
  dataChannel.send(photoBlob);
};

The P2P approach worked in testing but introduced complexity around NAT traversal (requiring STUN/TURN servers) and connection management as guests arrived and left. For now, the client-server model is more reliable, but WebRTC data channels remain on the roadmap for venues with poor internet connectivity.

Step 2: QR Codes — The Zero-Friction Entry Point

QR codes are the bridge between the physical event and the digital gallery. Every event on Picshots gets a unique QR code that, when scanned, opens the camera directly in the guest's browser. No typing URLs, no searching for the event — just point and shoot.

I used the qrcode npm package (82 million monthly downloads — it's basically the standard at this point) to generate QR codes server-side:

import QRCode from 'qrcode';

const eventUrl = `https://picshots.app/e/${eventId}`;
const qrSvg = await QRCode.toString(eventUrl, {
  type: 'svg',
  errorCorrectionLevel: 'H', // High — survives up to 30% damage
  margin: 2,
  width: 400,
  color: {
    dark: '#1a1a2e',
    light: '#ffffff'
  }
});

Key decisions here:

SVG over PNG: SVGs scale infinitely without pixelation. Event hosts print these QR codes on everything from table cards (2×2 inches) to welcome banners (4×6 feet). A PNG would look terrible at banner size.
Error correction level H: This allows the QR code to remain scannable even if up to 30% of it is damaged or obscured. At a wedding, QR codes get wine spilled on them, folded, or partially covered by centerpieces. Level H has saved countless scans.
Short URLs matter: The less data in a QR code, the larger and more scannable each module (those little squares) becomes. I use short event IDs (/e/abc123) rather than long UUIDs to keep the QR code clean and scannable from a distance. For the scanning side, I use html5-qrcode (5 million monthly downloads) for the rare case where someone needs to scan a QR code from within the browser — for example, if a host wants to join their own event from a laptop. It's pure JavaScript, no WebAssembly, and works reliably on mobile browsers.

Step 3: Capturing and Uploading Photos

Once the camera is running, capturing a photo is straightforward — grab a frame from the video stream and draw it to a canvas:

function capturePhoto(videoElement) {
  const canvas = document.createElement('canvas');
  canvas.width = videoElement.videoWidth;
  canvas.height = videoElement.videoHeight;

  const ctx = canvas.getContext('2d');
  ctx.drawImage(videoElement, 0, 0);

  return canvas.toBlob('image/jpeg', 0.85);
}

The upload pipeline is where things get interesting. I use presigned S3 URLs to bypass the server entirely during upload:

Client requests a presigned URL from the API
Client uploads directly to S3 using that URL
S3 triggers a Lambda that generates thumbnails and stores metadata in Supabase
Supabase Realtime pushes the new photo to all connected gallery viewers This architecture means my server never touches a single byte of image data. A 10MB photo from an iPhone 15 Pro Max goes straight from the guest's browser to S3. The server just handles metadata — event IDs, timestamps, and thumbnail URLs.

The real-time gallery update is powered by Supabase Realtime, which uses WebSockets under the hood. When a new photo row is inserted into the photos table, every connected client gets the update within milliseconds. At a wedding with 200 guests all watching the live gallery on a projector, the photos appear almost instantly after someone snaps them.

Step 4: The Hard Parts Nobody Talks About

iOS Safari and the "Page Reload" Problem

iOS Safari aggressively kills background tabs to save memory. If a guest switches to WhatsApp to reply to a message and comes back 30 seconds later, Safari may have killed the camera stream. The page reloads, and suddenly they're staring at the event landing page instead of the camera.

My fix: I store the camera state in sessionStorage. If the page reloads and detects a previous camera session, it auto-reopens the camera without requiring another QR scan. It's a small detail, but it's the difference between a guest taking 3 photos and taking 15.

Orientation Lock on Mobile

When a guest rotates their phone from portrait to landscape mid-capture, the video stream dimensions change. If you're not handling the resize event on the video element, your canvas capture will be stretched or cropped. I learned this the hard way when the first batch of test photos came back looking like funhouse mirrors.

video.addEventListener('resize', () => {
  canvas.width = video.videoWidth;
  canvas.height = video.videoHeight;
});

Concurrent Upload Limits

Browsers limit concurrent connections to the same origin (usually 6). At a wedding with 200 guests all uploading photos simultaneously, you can hit this limit fast. Presigned S3 URLs solve this because each upload goes to a unique URL — effectively bypassing the per-origin connection limit. I also added a simple upload queue with a concurrency limit of 3 to avoid overwhelming the device's network stack.

Step 5: The Gallery Experience

The gallery is where the magic happens. All photos appear in a responsive grid, sorted by capture time, with a subtle fade-in animation. Hosts can project the gallery on a screen at the venue, and guests can watch photos appear in real time throughout the night.

I built the gallery with a few key features:

Lazy loading with blur-up placeholders: Thumbnails load first as tiny (20×20) blurred images, then resolve to full resolution. On a gallery with 500+ photos, this keeps the initial page load under 2 seconds.
Infinite scroll with virtualization: Only ~20 photos are in the DOM at any time. As you scroll, photos are recycled. Without this, a 500-photo gallery would bring even a flagship phone to its knees.
Download all as ZIP: After the event, hosts can download every photo as a single ZIP file. This is generated server-side using archiver and streamed directly from S3 — no temporary files on disk.

The Results: What 12,000+ Events Taught Me

Since launching, Picshots has been used at over 12,000 events — weddings, birthday parties, corporate galas, baby showers, you name it. Here's what the data shows:

92% guest participation rate — meaning 92% of guests who scan the QR code take at least one photo
Average of 8.3 photos per guest — people don't just take one and leave; they come back throughout the night
Under 3 seconds from scan to first photo — the no-download, no-signup flow delivers on its promise
Zero app store reviews to manage — because there's no app. Bug fixes ship instantly to every user. The no-app approach turned out to be a superpower I didn't fully appreciate at first. When a guest at a wedding in Manila has an issue, I fix it on the server and it's resolved for everyone — no waiting for app store review, no forcing users to update. The web platform moves at the speed of git push.

What I'd Do Differently

If I were starting over today, I'd make three changes:

Use the BarcodeDetector API for QR scanning. It's now available in Chrome, Edge, and Samsung Internet, and it's hardware-accelerated — much faster than the pure-JS html5-qrcode library. I'd use it as the primary scanner with html5-qrcode as a fallback for Firefox and Safari.
Add WebP support from day one. I started with JPEG-only uploads. Switching to WebP reduced storage costs by 40% and improved gallery load times by 30%. Converting 12,000 events' worth of JPEGs to WebP was a migration I could have avoided.
Build the admin dashboard first, not last. I spent months perfecting the guest experience before realizing hosts needed tools too — event analytics, photo moderation, download management. The host dashboard now drives retention more than any guest-facing feature.

Should You Build Something Like This?

If you're thinking about building a browser-based camera app, here's my honest take: the browser camera APIs are mature enough for production use, but you'll spend 30% of your time on the happy path and 70% on edge cases. iOS Safari quirks, Android fragmentation, network conditions at event venues (hotel WiFi is notoriously terrible), and the sheer variety of device orientations and screen sizes will consume more development time than the core feature set.

That said, the payoff is real. There's something magical about watching a room full of people scan a QR code, open their camera, and start contributing to a shared gallery — all without installing anything. It feels like how technology should work.

If you want to see it in action, check out how Picshots works or try the Picshots for weddings experience yourself. I'd love to hear what you think.

What's the most creative use of the getUserMedia API you've seen? Have you built anything with browser camera access? Drop a comment — I'm always looking for inspiration for the next feature.

How I Built a No-App Photo Sharing Platform Using Just QR Codes and Browser Cameras

ArtiDigital — Tue, 11 Aug 2026 20:05:13 +0000

The Core Problem: Friction Kills Participation

The math is brutal:

App Store → find app → download → install → open → create account → verify email → find event → take photo = ~5% participation
Scan QR → camera opens → take photo → done = ~90% participation

That 85% gap is the difference between a dead gallery and one with 500+ photos by the end of the night. The no-download approach isn't a nice-to-have — it's the entire product.

The Tech Stack: What Powers a Browser-Based Photo Platform

Before diving into the code, here's the stack I landed on after several iterations:

LayerTechnologyWhy

Camera AccessMediaDevices.getUserMedia()Works in every modern browser, no polyfills needed
QR Generationqrcode (npm, 82M monthly downloads)Battle-tested, supports SVG output for crisp printing
QR Scanninghtml5-qrcode (npm, 5M monthly downloads)Pure JS, no WASM, works on mobile browsers
Image UploadPresigned S3 URLsBypasses server bottlenecks on large files
Real-time GallerySupabase RealtimeWebSocket-based, no polling, scales to thousands of concurrent viewers
FrontendNext.js + TailwindSSR for SEO pages, CSR for the camera experience
HostingVercel + S3 + SupabaseEdge functions for QR redirects, S3 for photos, Supabase for metadata

Let me walk through each piece and the decisions behind them.

Step 1: Accessing the Camera Without an App

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: 'environment', // Use back camera on mobile
    width: { ideal: 1920 },
    height: { ideal: 1080 }
  },
  audio: false
});

const video = document.getElementById('camera-preview');
video.srcObject = stream;
await video.play();

Three things I learned the hard way:

HTTPS is non-negotiable. getUserMedia only works on localhost or HTTPS. If you're testing on a device over your local network, you need a self-signed cert or a tunnel like ngrok. I wasted an afternoon debugging this before remembering it's a browser security requirement.
iOS Safari has quirks. On iOS, getUserMedia must be triggered by a user gesture (tap/click). You can't auto-open the camera on page load. I added a prominent "Open Camera" button that's impossible to miss, and the tap satisfies Safari's requirement.
The facingMode: 'environment' constraint is a suggestion, not a command. Some Android browsers ignore it and default to the front camera. I added a camera toggle button as a fallback — it's saved me from countless "why am I looking at my own face?" support messages.

media1.giphy.com

Why WebRTC Matters for Browser Camera Access

getUserMedia — accesses the camera and microphone (this is part of the WebRTC spec)
RTCPeerConnection — enables peer-to-peer audio/video/data transfer
RTCDataChannel — allows arbitrary data transfer between peers

Even though Picshots uses a client-server upload model for photos, WebRTC's getUserMedia is the foundation. The media constraints API (width, height, facingMode, frameRate) that I use to configure the camera are all part of the WebRTC specification. Without WebRTC standardizing these APIs across browsers, we'd be back to Flash plugins and ActiveX controls — the dark ages of web media.

// WebRTC P2P photo transfer prototype
const peerConnection = new RTCPeerConnection(config);
const dataChannel = peerConnection.createDataChannel('photos', {
  ordered: true,
  maxRetransmits: 3
});

dataChannel.onopen = () => {
  // Send photo blob directly to another guest
  dataChannel.send(photoBlob);
};

Step 2: QR Codes — The Zero-Friction Entry Point

I used the qrcode npm package (82 million monthly downloads — it's basically the standard at this point) to generate QR codes server-side:

import QRCode from 'qrcode';

const eventUrl = `https://picshots.app/e/${eventId}`;
const qrSvg = await QRCode.toString(eventUrl, {
  type: 'svg',
  errorCorrectionLevel: 'H', // High — survives up to 30% damage
  margin: 2,
  width: 400,
  color: {
    dark: '#1a1a2e',
    light: '#ffffff'
  }
});

Key decisions here:

SVG over PNG: SVGs scale infinitely without pixelation. Event hosts print these QR codes on everything from table cards (2×2 inches) to welcome banners (4×6 feet). A PNG would look terrible at banner size.
Error correction level H: This allows the QR code to remain scannable even if up to 30% of it is damaged or obscured. At a wedding, QR codes get wine spilled on them, folded, or partially covered by centerpieces. Level H has saved countless scans.
Short URLs matter: The less data in a QR code, the larger and more scannable each module (those little squares) becomes. I use short event IDs (/e/abc123) rather than long UUIDs to keep the QR code clean and scannable from a distance.

For the scanning side, I use html5-qrcode (5 million monthly downloads) for the rare case where someone needs to scan a QR code from within the browser — for example, if a host wants to join their own event from a laptop. It's pure JavaScript, no WebAssembly, and works reliably on mobile browsers.

Step 3: Capturing and Uploading Photos

Once the camera is running, capturing a photo is straightforward — grab a frame from the video stream and draw it to a canvas:

function capturePhoto(videoElement) {
  const canvas = document.createElement('canvas');
  canvas.width = videoElement.videoWidth;
  canvas.height = videoElement.videoHeight;

  const ctx = canvas.getContext('2d');
  ctx.drawImage(videoElement, 0, 0);

  return canvas.toBlob('image/jpeg', 0.85);
}

The upload pipeline is where things get interesting. I use presigned S3 URLs to bypass the server entirely during upload:

Client requests a presigned URL from the API
Client uploads directly to S3 using that URL
S3 triggers a Lambda that generates thumbnails and stores metadata in Supabase
Supabase Realtime pushes the new photo to all connected gallery viewers

This architecture means my server never touches a single byte of image data. A 10MB photo from an iPhone 15 Pro Max goes straight from the guest's browser to S3. The server just handles metadata — event IDs, timestamps, and thumbnail URLs.

media1.giphy.com

Step 4: The Hard Parts Nobody Talks About

iOS Safari and the "Page Reload" Problem

Orientation Lock on Mobile

video.addEventListener('resize', () => {
  canvas.width = video.videoWidth;
  canvas.height = video.videoHeight;
});

Concurrent Upload Limits

Step 5: The Gallery Experience

I built the gallery with a few key features:

Lazy loading with blur-up placeholders: Thumbnails load first as tiny (20×20) blurred images, then resolve to full resolution. On a gallery with 500+ photos, this keeps the initial page load under 2 seconds.
Infinite scroll with virtualization: Only ~20 photos are in the DOM at any time. As you scroll, photos are recycled. Without this, a 500-photo gallery would bring even a flagship phone to its knees.
Download all as ZIP: After the event, hosts can download every photo as a single ZIP file. This is generated server-side using archiver and streamed directly from S3 — no temporary files on disk.

The Results: What 12,000+ Events Taught Me

Since launching, Picshots has been used at over 12,000 events — weddings, birthday parties, corporate galas, baby showers, you name it. Here's what the data shows:

92% guest participation rate — meaning 92% of guests who scan the QR code take at least one photo
Average of 8.3 photos per guest — people don't just take one and leave; they come back throughout the night
Under 3 seconds from scan to first photo — the no-download, no-signup flow delivers on its promise
Zero app store reviews to manage — because there's no app. Bug fixes ship instantly to every user.

The no-app approach turned out to be a superpower I didn't fully appreciate at first. When a guest at a wedding in Manila has an issue, I fix it on the server and it's resolved for everyone — no waiting for app store review, no forcing users to update. The web platform moves at the speed of git push.

media0.giphy.com

What I'd Do Differently

If I were starting over today, I'd make three changes:

Use the BarcodeDetector API for QR scanning. It's now available in Chrome, Edge, and Samsung Internet, and it's hardware-accelerated — much faster than the pure-JS html5-qrcode library. I'd use it as the primary scanner with html5-qrcode as a fallback for Firefox and Safari.
Add WebP support from day one. I started with JPEG-only uploads. Switching to WebP reduced storage costs by 40% and improved gallery load times by 30%. Converting 12,000 events' worth of JPEGs to WebP was a migration I could have avoided.
Build the admin dashboard first, not last. I spent months perfecting the guest experience before realizing hosts needed tools too — event analytics, photo moderation, download management. The host dashboard now drives retention more than any guest-facing feature.

Should You Build Something Like This?

If you want to see it in action, check out how Picshots works or try the Picshots for weddings yourself. I'd love to hear what you think.

What's the most creative use of the getUserMedia API you've seen? Have you built anything with browser camera access? Drop a comment — I'm always looking for inspiration for the next feature.

How I Built a No-App Photo Sharing Platform Using Just QR Codes and Browser Cameras

ArtiDigital — Tue, 11 Aug 2026 19:00:07 +0000

The Spark: Why I Decided to Build a Camera App Without an App

I've already written about the UX decision to go app-free — the brutal conversion funnel, the 18% upload rate, the moment my aunt said "I have to download something? Never mind." That article was about the why. This one is about the how.

Because here's the thing: saying "just use the browser camera" is easy. Actually building a camera experience in a browser that doesn't feel like a 2007 flip phone? That's a different beast entirely. This is the technical story of how I built Picshots — a no-app photo sharing platform where guests scan a QR code and start shooting from their phone browser — and the stack, the dead ends, and the "oh wow that actually works" moments along the way.

The Architecture: Three Moving Parts

At its core, the platform has three technical components that need to work together seamlessly:

QR Code Generation & Scanning — Each event gets a unique QR code. Guests scan it and land on the event's photo page. No typing URLs, no searching app stores.
Browser Camera Access — Once on the page, the browser needs to access the phone's camera, capture high-quality photos, and handle all the edge cases (orientation, flash, permissions, different browsers).
Real-Time Photo Gallery — Photos need to upload and appear in a shared gallery that updates live, so the host can project it on a screen or guests can browse what others have captured.

Let me walk through each one, including the code, the gotchas, and the libraries that saved me months of work.

Part 1: QR Codes — The Zero-Friction Entry Point

The QR code is the entire distribution strategy. No app store, no search, no typing. Just point your phone camera and you're in. But generating QR codes that work reliably across every phone — from a brand-new iPhone 16 to a five-year-old budget Android — is trickier than it looks.

Choosing a QR Library

I evaluated three approaches:

Server-side generation (Node.js + qrcode package): 82 million monthly npm downloads, battle-tested, supports every format. The safe choice.
Client-side generation (qrcode-generator or Canvas API): No server round-trip, but heavier on the client and inconsistent across browsers.
Third-party API (Google Charts, QR Server): Adds an external dependency and latency. No thanks.

I went with server-side generation using the qrcode npm package. Here's the core logic:

const QRCode = require('qrcode');

async function generateEventQR(eventId, eventUrl) {
  const qrDataUrl = await QRCode.toDataURL(eventUrl, {
    width: 600,
    margin: 2,
    color: {
      dark: '#1A1A2E',
      light: '#FFFFFF'
    },
    errorCorrectionLevel: 'M'
  });

  return qrDataUrl;
}

Why Error Correction Level Matters

I initially used error correction level L (lowest, ~7% recovery) because it produces smaller, cleaner QR codes. Big mistake. At a dimly-lit wedding reception, guests' phone cameras struggle with low-contrast QR codes. Bumping to level M (~15% recovery) made the codes slightly denser but dramatically more scannable in poor lighting. For events where the QR code gets printed on textured paper or curved surfaces (wine bottles, table tents), I'd even recommend level Q (~25%).

The QR code also needed to survive being printed at different sizes — from a 2-inch table card to a 6-foot projection screen. The width: 600 parameter generates a high-enough resolution SVG/PNG that scales cleanly in both directions without pixelation.

Dynamic QR Codes, Not Static

One architectural decision I'm glad I made early: every QR code encodes a dynamic URL (picshots.app/e/{eventId}), not a static one. This means I can change where that URL points without regenerating the QR code. If I ever need to migrate domains, add tracking parameters, or A/B test different landing experiences, the QR codes keep working. Static QR codes are technical debt you print onto physical cards.

Part 2: The Browser Camera — Making getUserMedia Feel Native

This is where things got interesting. The getUserMedia API has been around since 2015, but using it to build a camera that feels like a native camera app requires solving a cascade of problems that the basic MDN tutorial doesn't mention.

The Basic Setup

Here's the starting point — the minimum viable camera:

async function startCamera() {
  try {
    const stream = await navigator.mediaDevices.getUserMedia({
      video: {
        facingMode: 'environment',
        width: { ideal: 1920 },
        height: { ideal: 1080 }
      },
      audio: false
    });

    const video = document.getElementById('camera-preview');
    video.srcObject = stream;
    video.play();

    return stream;
  } catch (err) {
    console.error('Camera access failed:', err);
    // Handle permission denied, no camera, etc.
  }
}

The facingMode: 'environment' constraint is critical. Without it, most browsers default to the front-facing selfie camera — useless for taking photos of other people at an event. But here's the catch: facingMode is a constraint, not a guarantee. If the device doesn't have a rear camera (rare but possible with some tablets), the browser will fall back to whatever camera is available. You need to handle that gracefully.

Capturing High-Quality Still Photos

The getUserMedia stream gives you a video feed, not a photo. To capture a still image, you have two options:

Option A: Canvas capture (works everywhere)

function capturePhoto(videoElement) {
  const canvas = document.createElement('canvas');
  canvas.width = videoElement.videoWidth;
  canvas.height = videoElement.videoHeight;

  const ctx = canvas.getContext('2d');
  ctx.drawImage(videoElement, 0, 0);

  return canvas.toDataURL('image/jpeg', 0.92);
}

Option B: ImageCapture API (Chromium only, higher quality)

async function capturePhotoHQ(track) {
  const imageCapture = new ImageCapture(track);
  const blob = await imageCapture.takePhoto({
    imageWidth: 1920,
    imageHeight: 1080
  });
  return URL.createObjectURL(blob);
}

I use both. The ImageCapture API produces noticeably sharper photos because it grabs a full-resolution frame directly from the sensor, bypassing the video pipeline. But it's only supported in Chromium-based browsers (Chrome, Edge, Samsung Internet). For Safari and Firefox, I fall back to canvas capture. The quality difference is visible — canvas-captured photos are slightly softer — but it's the difference between "good enough for a wedding" and "good enough for a wedding."

The Orientation Nightmare

This is the bug that ate two weeks of my life. Mobile browsers report video orientation differently depending on the OS, the browser, and the phase of the moon. Photos would come in sideways on iOS Safari, upside down on some Android devices, and correctly on others. The EXIF orientation tags that native camera apps use to signal rotation? getUserMedia doesn't set them.

Here's the orientation correction logic I landed on after four rewrites:

function correctOrientation(canvas, videoElement) {
  const ctx = canvas.getContext('2d');
  const videoWidth = videoElement.videoWidth;
  const videoHeight = videoElement.videoHeight;

  // Detect device orientation
  const isPortrait = window.innerHeight > window.innerWidth;
  const isIOS = /iPad|iPhone|iPod/.test(navigator.userAgent);

  if (isPortrait && isIOS) {
    // iOS Safari reports landscape video in portrait mode
    canvas.width = videoHeight;
    canvas.height = videoWidth;
    ctx.translate(canvas.width, 0);
    ctx.rotate(Math.PI / 2);
  } else if (isPortrait) {
    // Android Chrome usually gets this right, but not always
    canvas.width = videoWidth;
    canvas.height = videoHeight;
  } else {
    canvas.width = videoWidth;
    canvas.height = videoHeight;
  }

  ctx.drawImage(videoElement, 0, 0, videoWidth, videoHeight);
}

I'm not going to pretend this is elegant. It's a pile of device-specific hacks held together by user-agent sniffing, which every web developer knows is a sin. But after testing across 30+ device/browser combinations, this is what actually works. Sometimes the right solution is the ugly one.

The Flashlight Surprise

One discovery that genuinely delighted me: you can control the phone's flashlight through the browser. The ImageCapture API exposes a torch capability:

async function toggleFlash(stream, enabled) {
  const track = stream.getVideoTracks()[0];
  const capabilities = track.getCapabilities();

  if (capabilities.torch) {
    await track.applyConstraints({
      advanced: [{ torch: enabled }]
    });
    return true;
  }
  return false; // No flash available
}

At dimly-lit wedding receptions, this feature alone makes the browser camera feel like a real camera. Guests tap a flash icon, the phone's LED lights up, and suddenly their photos aren't grainy messes. It's one of those features that makes users forget they're not in a native app.

Part 3: Real-Time Gallery — Making Photos Appear Instantly

The third piece of the puzzle is the shared gallery. When a guest takes a photo, it needs to appear in the event gallery — ideally in real time — so the host can project it on a screen or other guests can see what's been captured.

Upload Resilience on Terrible WiFi

Wedding venues have notoriously bad internet. Barns, gardens, beach resorts, hotel ballrooms — none of these are known for their gigabit fiber. I needed uploads to work even when the connection drops mid-transfer.

I built a retry queue with exponential backoff:

class UploadQueue {
  constructor() {
    this.queue = [];
    this.processing = false;
    this.maxRetries = 5;
  }

  async add(file, eventId) {
    this.queue.push({ file, eventId, retries: 0 });
    if (!this.processing) this.process();
  }

  async process() {
    this.processing = true;
    while (this.queue.length > 0) {
      const item = this.queue[0];
      try {
        await this.uploadFile(item.file, item.eventId);
        this.queue.shift(); // Success, remove from queue
      } catch (err) {
        item.retries++;
        if (item.retries >= this.maxRetries) {
          console.error('Upload failed after max retries:', item);
          this.queue.shift(); // Give up
        } else {
          // Exponential backoff: 1s, 2s, 4s, 8s, 16s
          const delay = Math.pow(2, item.retries) * 1000;
          await new Promise(r => setTimeout(r, delay));
        }
      }
    }
    this.processing = false;
  }

  async uploadFile(file, eventId) {
    const formData = new FormData();
    formData.append('photo', file);
    formData.append('eventId', eventId);

    const response = await fetch('/api/upload', {
      method: 'POST',
      body: formData
    });

    if (!response.ok) throw new Error('Upload failed');
    return response.json();
  }
}

For the real-time gallery updates, I use Supabase's real-time subscriptions. When a photo is uploaded, the backend inserts a row into the photos table, and every connected client receives the new photo via a WebSocket subscription. No polling, no manual refresh — the gallery just updates.

Why Not WebRTC?

You might wonder: if this is about photo sharing, why not use WebRTC for peer-to-peer transfer? I explored this. WebRTC would let guests send photos directly to each other without hitting a server. But for an event photo sharing platform, it's the wrong architecture:

WebRTC needs signaling servers anyway — you still need a server to establish the peer connection, so you're not actually serverless.
NAT traversal is unreliable on venue networks — hotel and venue WiFi often blocks the UDP ports WebRTC needs for STUN/TURN.
The host needs a central gallery — peer-to-peer means photos live on individual devices. The whole point of Picshots is one shared gallery the host controls.
Guests come and go — if the only person who has a photo leaves the event, that photo is gone from the P2P mesh.

WebRTC is brilliant for video calls and file transfers between two consenting peers. For a shared event gallery with a host who needs persistent access to all photos, a client-server model with real-time subscriptions is the right call.

The Stack, Summarized

Here's the full technical stack that powers the no-app photo sharing experience:

Frontend: Vanilla JavaScript (no framework — keep the bundle tiny for fast QR code landing page loads)
Camera: getUserMedia + ImageCapture API with canvas fallback
QR Generation: qrcode npm package (82M monthly downloads), server-side, error correction level M
QR Scanning: BarcodeDetector API (Chromium) + html5-qrcode polyfill (5M monthly downloads) for Safari
Uploads: Retry queue with exponential backoff, chunked uploads for large files
Real-Time Gallery: Supabase Realtime (WebSocket subscriptions)
Storage: Supabase Storage for photos, Supabase Postgres for metadata
Hosting: Static site on CDN, API on a lightweight Node.js server

What I'd Do Differently

Building in public means being honest about the mistakes. Here are mine:

1. I should have tested on more Android devices earlier. I developed primarily on an iPhone and a Pixel. The first time someone tried Picshots on a $150 Samsung from 2021, the camera preview was 3 FPS and the flash didn't work. I now maintain a device lab of 8 phones spanning iOS and Android at different price points.

2. The orientation fix should have been a standalone library. I wrote orientation correction inline, then rewrote it, then rewrote it again. If I'd extracted it into a small, testable module from day one, I would have saved myself two weeks of debugging. If you're doing anything with getUserMedia and mobile, isolate your orientation logic.

3. I underestimated how much guests care about photo quality. My first prototype used a 640x480 canvas capture with JPEG quality 0.7. The photos looked fine on a phone screen but terrible when the host tried to print them or view them on a laptop. Bumping to 1920x1080 with quality 0.92 made uploads slower but made the product actually usable for its intended purpose — preserving memories.

Try It Yourself

If you're building something that needs browser camera access, here's my advice: start with the simplest possible implementation and test it on real devices immediately. The gap between "works on my machine" and "works at a wedding with 200 guests on terrible WiFi" is enormous, and you won't find it in a simulator.

The web platform is absurdly capable now. Between getUserMedia, ImageCapture, the BarcodeDetector API, service workers, and WebSocket-based real-time subscriptions, you can build experiences that feel native without asking anyone to install anything. The "no app" approach isn't just a UX preference — it's a distribution strategy that removes the single biggest barrier between your users and the value you're providing.

If you want to see how it all comes together, check out how Picshots works or create your own event to try the QR code + browser camera flow yourself. No download required — that's the whole point.

I'm building Picshots in public. Follow along for more technical deep-dives, including how I handle video uploads from the browser, the Supabase schema that powers the real-time gallery, and the analytics pipeline that helps hosts understand which guests are actually taking photos. No corporate blog posts, no PR-filtered success stories — just what actually happens when you try to build something people want.

How I Built a No-App Photo Sharing Platform Using Just QR Codes and Browser Cameras

ArtiDigital — Tue, 11 Aug 2026 18:00:15 +0000

The Problem: Everyone Has a Phone, Nobody Shares Photos

Last summer, I attended my cousin's wedding. 200 guests, all with smartphones, all taking photos. The couple spent $3,000 on a professional photographer, but the candid moments — the ones that actually tell the story of the day — were scattered across 200 camera rolls. A week later, the couple had maybe 30 photos from guests, shared through a chaotic mix of WhatsApp, AirDrop, and "I'll send them later" promises that never materialized.

That's when the idea hit me: what if every table at a wedding had a QR code that guests could scan to instantly take and share photos — without downloading a single app?

I called it Picshots. Here's how I built it, what I learned, and the technical decisions that made it work.

The Core Bet: Browser Cameras Are Good Enough

The first question I had to answer was: can you actually build a decent camera experience in a browser? In 2026, the answer is a resounding yes — but it wasn't always obvious.

getUserMedia: The Gateway API

The foundation of everything is the MediaDevices.getUserMedia() API. It's been around since Chrome 53 and Firefox 36, but the real game-changer was when Safari finally added support in iOS 11. That meant every modern phone could access its camera from a web page.

Here's the basic flow I started with:

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: 'environment', // Use the back camera
    width: { ideal: 1920 },
    height: { ideal: 1080 }
  }
});
videoElement.srcObject = stream;

The facingMode: 'environment' constraint was critical. By default, most browsers open the front-facing selfie camera, which is useless for taking photos of other people. Setting it to 'environment' forces the rear camera — exactly what you want for event photography.

The Flash Surprise

One thing I didn't expect: you can actually trigger the phone's flashlight through the browser. The ImageCapture API (part of the MediaStream Image Capture spec) exposes a torch property on the photo capabilities:

const track = stream.getVideoTracks()[0];
const capabilities = track.getCapabilities();
if (capabilities.torch) {
  await track.applyConstraints({ advanced: [{ torch: true }] });
}

This was a delightful discovery. At dimly-lit wedding receptions, having the flash work through the browser made a massive difference in photo quality. It's one of those features that makes users forget they're not in a native app.

QR Codes: The Zero-Friction Entry Point

The second pillar of the no-app approach is QR codes. No typing URLs, no searching app stores, no creating accounts. Just point your camera and go.

Generating QR Codes Server-Side

I used the qrcode npm package (82 million monthly downloads — it's battle-tested) to generate QR codes dynamically for each event:

const QRCode = require('qrcode');

async function generateEventQR(eventId) {
  const url = `https://picshots.app/e/${eventId}`;
  const qrDataUrl = await QRCode.toDataURL(url, {
    width: 400,
    margin: 2,
    color: {
      dark: '#1a1a2e',
      light: '#ffffff'
    },
    errorCorrectionLevel: 'M'
  });
  return qrDataUrl;
}

I chose error correction level M (medium, ~15% recovery) as the sweet spot. Level H (high, ~30%) makes the QR code denser and harder to scan from a distance, while L (low, ~7%) is too fragile for printed codes that might get smudged or partially covered at an event.

The QR-to-Camera Flow

Here's the user journey I designed:

Event host creates an event on Picshots and gets a unique QR code
They print the QR code and place it on tables, near the dance floor, at the photo booth
Guests scan the QR code with their phone's native camera app
The link opens in their browser — no app store redirect, no sign-up wall
The browser requests camera permission once
Guests take photos that upload directly to the event gallery

The entire flow from scan to first photo takes under 5 seconds. That's faster than finding an app in the App Store, let alone downloading and installing one.

The Technical Architecture

Let me walk through the stack and the key decisions.

Frontend: Vanilla JS with a Sprinkle of Modern APIs

I deliberately kept the frontend lightweight. No React, no Vue, no build step. Here's why:

Bundle size matters on slow event WiFi. A 200KB JavaScript framework is a liability when 50 guests are trying to load the page simultaneously on a venue's congested network.
The camera API is imperative, not declarative. React's component model doesn't map cleanly to managing media streams, tracks, and constraints. Vanilla JS with direct DOM manipulation was actually cleaner.
Fewer dependencies = fewer breaking changes. I wanted this to work for years without maintenance.

The entire camera page is ~12KB of minified JavaScript. It loads in under 300ms on a 3G connection.

Image Capture and Upload

For actually capturing the photo, I used the ImageCapture API where available, with a canvas fallback:

async function capturePhoto(videoTrack) {
  if (window.ImageCapture) {
    const imageCapture = new ImageCapture(videoTrack);
    const blob = await imageCapture.takePhoto({
      imageWidth: 1920,
      imageHeight: 1080
    });
    return blob;
  }

  // Canvas fallback for browsers without ImageCapture
  const canvas = document.createElement('canvas');
  canvas.width = video.videoWidth;
  canvas.height = video.videoHeight;
  canvas.getContext('2d').drawImage(video, 0, 0);

  return new Promise(resolve => {
    canvas.toBlob(resolve, 'image/jpeg', 0.85);
  });
}

The ImageCapture.takePhoto() method is superior because it captures at the sensor's native resolution, not the video feed resolution. On most phones, that's the difference between a 2MP video frame and a 12MP photo. The canvas fallback is fine for older devices, but the quality difference is noticeable.

Real-Time Gallery with Server-Sent Events

For the live gallery — where photos appear in real-time as guests take them — I chose Server-Sent Events (SSE) over WebSockets:

// Server (Node.js + Express)
app.get('/api/events/:id/live', (req, res) => {
  res.writeHead(200, {
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-cache',
    'Connection': 'keep-alive'
  });

  const listener = (photo) => {
    res.write(`data: ${JSON.stringify(photo)}\n\n`);
  };

  eventEmitter.on(`photo:${req.params.id}`, listener);

  req.on('close', () => {
    eventEmitter.off(`photo:${req.params.id}`, listener);
  });
});

SSE is simpler than WebSockets for a one-way data flow (server → client), works through most proxies without special configuration, and reconnects automatically when the connection drops. At a wedding where guests are moving between WiFi and cellular, that auto-reconnect is essential.

Storage: Optimizing for the Event Use Case

Photos are uploaded as JPEG blobs, compressed client-side to ~85% quality before upload. This keeps individual photos under 500KB while maintaining print-quality resolution. For a typical wedding with 500-800 photos, that's 250-400MB total — manageable for cloud storage without breaking the bank.

I store originals in S3-compatible object storage and generate WebP thumbnails (200px wide) for the gallery view. The gallery loads fast even on slow connections because each thumbnail is only ~8KB.

The Hard Parts Nobody Talks About

iOS Safari and the "Not in Full Screen" Problem

iOS Safari has a peculiar restriction: getUserMedia only works in a secure context (HTTPS) and requires the page to be in a "full screen" or standalone mode for certain features. If the user opens the link from the native camera app's QR scanner, it opens in an SFSafariViewController, which sometimes blocks camera access.

The workaround: I added a prominent "Open in Safari" button that appears when the page detects it's running in an in-app browser. It uses a simple user-agent check:

const isInAppBrowser = 
  /FBAN|FBAV|Instagram|Twitter|Line/.test(navigator.userAgent) ||
  (navigator.standalone === false && 
   /Safari/.test(navigator.userAgent) &&
   /iPhone/.test(navigator.userAgent) &&
   !/CriOS|FxiOS|OPiOS|mercury/.test(navigator.userAgent));

Not elegant, but it works. About 15% of users hit this flow, and the "Open in Safari" button converts about 80% of them.

The "I Don't Want to Give Camera Access" Problem

Some guests are understandably wary of granting camera permissions to a random website. I addressed this in two ways:

Transparent UI: The camera preview shows exactly what the camera sees before any photo is taken. There's no hidden capture.
Local-first messaging: The page explicitly states "Photos are only uploaded when you tap the shutter button. Nothing is recorded until you choose to share."

This reduced the camera-permission denial rate from ~40% (in early testing) to under 10%.

Concurrent Uploads at Scale

At a 200-person wedding, you might have 30-40 people taking photos simultaneously. Each photo upload is a multipart form upload. Node.js handles this fine with streaming, but I added a simple queue on the client side to prevent overwhelming the server:

const uploadQueue = [];
let uploading = false;

async function processQueue() {
  if (uploading || uploadQueue.length === 0) return;
  uploading = true;
  const { blob, eventId } = uploadQueue.shift();
  try {
    await uploadPhoto(blob, eventId);
  } finally {
    uploading = false;
    processQueue();
  }
}

This ensures each client uploads one photo at a time, which prevents the browser from opening 6 simultaneous connections and saturating the venue's WiFi.

What I'd Do Differently

After running this for over a year and processing photos from thousands of events, here's what I've learned:

1. WebRTC Would Have Been Overkill

Early on, I considered using WebRTC for peer-to-peer photo transfer between guests. The idea was that guests could share photos directly without hitting the server. I spent two weeks prototyping this before realizing it was solving a problem that didn't exist. Server uploads are fast enough, and the complexity of WebRTC signaling, STUN/TURN servers, and NAT traversal wasn't worth it for a photo-sharing use case.

2. The BarcodeDetector API Is Underrated

I initially used the html5-qrcode library (5M monthly npm downloads) for in-browser QR scanning on the admin side. But Chrome now ships with a native BarcodeDetector API that's faster and more accurate:

const detector = new BarcodeDetector({
  formats: ['qr_code']
});
const barcodes = await detector.detect(imageBitmap);

It's only available in Chrome and Edge (not Firefox or Safari yet), but for the admin dashboard where I control the browser, it's a no-brainer. The native detector is 3-4x faster than the JS library.

3. Offline Support Matters More Than I Thought

Wedding venues are notorious for bad cell service. I added a Service Worker with a simple cache-first strategy for the camera page itself, so even if the network drops, guests can still access the camera interface. Photos queue locally in IndexedDB and upload when connectivity returns. This was a weekend project that paid for itself in the first real-world test.

The Results

After 12 months, here are the numbers:

12,000+ events hosted on the platform
Average 180 photos per event (compared to ~30 with the "please send photos later" approach)
92% guest participation rate (guests who scan the QR code actually take at least one photo)
Under 3 seconds average time from QR scan to first photo

The no-app approach works. Guests don't want to download another app for a one-time event. They want to scan, snap, and get back to celebrating. The browser is the perfect delivery mechanism for that.

The Stack at a Glance

LayerTechnologyWhyCameragetUserMedia + ImageCapture APINative browser APIs, no pluginsQR Generationqrcode (npm)82M monthly downloads, battle-testedFrontendVanilla JS (~12KB)Fast load on slow event WiFiReal-timeServer-Sent EventsSimpler than WebSockets, auto-reconnectStorageS3-compatible + WebP thumbsCheap, scalable, fast gallery loadsOfflineService Worker + IndexedDBWorks when venue WiFi doesn'tHostingNode.js on a $20 VPSHandles 500+ concurrent guests

Want to Try It?

If you're curious about how the full flow works, check out how Picshots works — I've documented the entire guest experience from QR scan to gallery view. And if you have an event coming up, you can create your own event and see the no-app camera experience in action.

The code isn't open source (yet — I'm still deciding), but I'm happy to answer technical questions in the comments. What would you have done differently? Have you built something with the browser camera API? I'd love to hear about your experience.

Why I Made PicShots App-Free: The UX Decision That Doubled Guest Photo Uploads

ArtiDigital — Tue, 11 Aug 2026 15:36:14 +0000

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.

How I Built a No-App Photo Sharing Platform Using Just QR Codes and Browser Cameras

ArtiDigital — Tue, 11 Aug 2026 15:32:41 +0000

The Problem (Picshots)

Last month, I was at a friend's wedding. 200 guests, all with smartphones, and the couple wanted one thing: a shared photo album everyone could contribute to without downloading anything. No app store. No sign-up. No "create an account to view these photos." Just point, shoot, and share.

I looked at existing solutions. Google Photos shared albums require a Google account. Wedding-specific apps like The Guest push you through app store installs. WhatsApp groups compress images to oblivion. Dropbox file requests still need the Dropbox app for a smooth mobile experience.

So I built something different: a web app that uses QR codes for instant access and the browser's camera API for photo capture. Zero installs. Zero accounts. One QR code.

The Architecture

The stack is deliberately boring — I wanted this to work reliably, not impress Hacker News:

Frontend: Vanilla HTML/CSS/JS with the html5-qrcode library for scanning and the MediaDevices API for camera access
Backend: Node.js with Express, handling file uploads via Multer
Storage: Local filesystem with a cron job to purge photos after 30 days
QR Generation: The qrcode npm package, generating codes server-side
Deployment: A $6/month DigitalOcean droplet running behind Nginx with Let's Encrypt SSL

The flow is dead simple: the host generates a QR code from the dashboard, prints it or displays it on a screen, guests scan it with their phone camera, and they're instantly on the capture page — no typing URLs, no app installs.

QR Code Implementation

Generating QR codes is the easy part. The qrcode package handles everything:

const QRCode = require('qrcode');

async function generateEventQR(eventId) {
  const url = `https://snapshare.app/e/${eventId}`;
  const qrDataUrl = await QRCode.toDataURL(url, {
    width: 600,
    margin: 2,
    color: {
      dark: '#1a1a2e',
      light: '#ffffff'
    },
    errorCorrectionLevel: 'H'  // 30% damage recovery
  });
  return qrDataUrl;
}

A few things I learned the hard way:

Error correction level matters. I started with 'L' (7% recovery) and had guests at an outdoor evening event struggling because the printed QR code got slightly smudged. Bumping to 'H' (30%) made the codes slightly denser but dramatically more reliable in the real world.

URL length vs. QR density. The longer your URL, the denser the QR code. I kept event IDs to 8-character nanoids instead of UUIDs, which kept the URLs short and the QR codes scannable from across a room.

Dynamic vs. static QR codes. I generate QR codes dynamically per event rather than pre-generating them. Each event gets a unique URL with a short-lived token embedded, so even if someone leaks the QR code, it expires with the event.

Browser Camera Integration

This is where things got interesting. The MediaDevices API (getUserMedia) is powerful but temperamental across browsers and devices.

The Basic Setup

async function initCamera() {
  const constraints = {
    video: {
      facingMode: 'environment',  // back camera
      width: { ideal: 1920 },
      height: { ideal: 1080 }
    }
  };

  try {
    const stream = await navigator.mediaDevices.getUserMedia(constraints);
    videoElement.srcObject = stream;
  } catch (err) {
    // Fallback: some browsers don't support facingMode
    const fallbackStream = await navigator.mediaDevices.getUserMedia({
      video: true
    });
    videoElement.srcObject = fallbackStream;
  }
}

The Real-World Problems

iOS Safari and the "green dot" paranoia. Starting with iOS 14, Safari shows a prominent green dot when the camera is active. Some guests thought they were being recorded continuously. I added a clear UI indicator — a pulsing red circle with "Camera active — photo captured only when you tap" — which eliminated the confusion.

Android Chrome and autofocus. On mid-range Android devices, the camera would hunt for focus endlessly, draining battery. I added a one-shot autofocus trigger on tap-to-capture:

async function capturePhoto() {
  const track = stream.getVideoTracks()[0];
  const capabilities = track.getCapabilities();

  if (capabilities.focusMode?.includes('single-shot')) {
    await track.applyConstraints({
      advanced: [{ focusMode: 'single-shot' }]
    });
  }

  // Small delay for focus to settle
  await new Promise(r => setTimeout(r, 300));

  canvasContext.drawImage(videoElement, 0, 0);
  const blob = await canvasToBlob(canvas);
  await uploadPhoto(blob);
}

The orientation nightmare. Photos taken in portrait mode would appear rotated when displayed. The EXIF orientation data from getUserMedia is inconsistent across browsers. My solution: read the image on a canvas, detect the actual dimensions, and rotate server-side if needed. Not elegant, but it works everywhere.

Check out explore events. Check out our create your event.### QR Code Scanning (The Other Direction)

For the host to scan guest-submitted QR codes (for moderation or linking), I used html5-qrcode:

const scanner = new Html5Qrcode('reader');

scanner.start(
  { facingMode: 'environment' },
  { fps: 10, qrbox: 250 },
  (decodedText) => {
    window.location.href = decodedText;
    scanner.stop();
  },
  (errorMessage) => {
    // Ignore — scanning is continuous
  }
);

The key insight: set fps: 10 not 30. Higher FPS burns CPU and battery for no benefit — QR codes don't move.

The No-App Philosophy

The "no-app" part isn't just a feature — it's the entire product philosophy. Here's what I mean:

No app store friction. The average person installs zero new apps per month. Asking 200 wedding guests to install something is a non-starter. A URL behind a QR code has zero friction.

No account creation. Every sign-up form loses 60-80% of users. My platform uses event-based tokens: the QR code URL contains a short-lived JWT that authenticates the guest to that specific event. No email, no password, no social login.

No data retention anxiety. Photos auto-delete after 30 days. Guests know their photos aren't being mined for training data or sold to advertisers. The privacy model is: "your photos, your event, then gone."

Progressive Web App as the sweet spot. I added a service worker so returning guests get a slightly faster load, but I deliberately didn't push "Add to Home Screen." The whole point is that you shouldn't need to.

The Backend: Keep It Dumb

The backend does exactly three things:

Generate QR codes for new events
Accept photo uploads via multipart form data
Serve photos with short-lived signed URLs

// Event creation endpoint
app.post('/api/events', async (req, res) => {
  const eventId = nanoid(8);
  const token = jwt.sign({ eventId, role: 'guest' }, 
    process.env.JWT_SECRET, 
    { expiresIn: '7d' }
  );

  const url = `https://snapshare.app/e/${eventId}?t=${token}`;
  const qrCode = await QRCode.toDataURL(url, { 
    errorCorrectionLevel: 'H' 
  });

  await db.events.insert({ 
    id: eventId, 
    created: new Date(),
    expires: new Date(Date.now() + 30 * 86400000)
  });

  res.json({ eventId, qrCode, url });
});

No user management. No complex permissions. No real-time features (those came later, and honestly, they weren't worth the complexity for the use case).

Challenges That Almost Broke Me

1. iOS WebRTC permissions are per-session. Every time a guest switches away from Safari and comes back, the camera permission prompt fires again. There's no way around this — it's an OS-level security decision. I added a prominent "Tap to re-enable camera" button that appears when the stream disconnects.

2. Large photo uploads on slow connections. Wedding venues often have terrible cell reception. A 12MP photo is 3-8MB. On EDGE-speed connections, that's a 2-minute upload. I added client-side compression:

function compressImage(file, maxWidth = 1920, quality = 0.85) {
  return new Promise((resolve) => {
    const img = new Image();
    img.onload = () => {
      const canvas = document.createElement('canvas');
      const ratio = Math.min(maxWidth / img.width, 1);
      canvas.width = img.width * ratio;
      canvas.height = img.height * ratio;
      canvas.getContext('2d').drawImage(img, 0, 0, canvas.width, canvas.height);
      canvas.toBlob(resolve, 'image/jpeg', quality);
    };
    img.src = URL.createObjectURL(file);
  });
}

This brought uploads down to 200-500KB with negligible quality loss for social sharing.

3. The "someone took a photo of the floor" problem. Without moderation, photo albums fill with accidental shots. I added an optional blur-detection pass using the Canvas API to flag likely-bad photos, but ultimately the best solution was giving the event host a simple moderation dashboard.

What I'd Do Differently

Use S3 from day one. Local filesystem storage works until you need to scale or back up. Migrating 50GB of photos from a DigitalOcean volume to S3-compatible storage mid-project was not fun.

Add a loading skeleton immediately. The camera initialization takes 1-3 seconds on most devices. Without a skeleton UI, guests thought the page was broken. A simple pulsing placeholder would have saved me dozens of "it's not working" messages.

You might also like our wedding guest camera. You might also find our create your event useful.Test on older devices earlier. I developed on an iPhone 15 and Pixel 8. The first real-world test was at a family gathering where my aunt's iPhone 8 couldn't maintain a stable video stream. Turns out, requesting 1080p on older devices causes the stream to stutter. Adding a capability check and falling back to 720p fixed it.

The Results

Over three months and 15 events (weddings, birthday parties, corporate gatherings), the platform handled:

4,200+ photos uploaded
800+ unique guests (zero app installs)
Average session time: 2 minutes 40 seconds
Photo upload success rate: 94% (the 6% failures were almost entirely network timeouts on poor connections)

The best feedback came from a bride who said: "My 78-year-old grandmother figured it out in 30 seconds. She's never used anything but the Phone and Messages apps."

The Code

The full project is open source. The key libraries used:

qrcode — QR code generation (82M+ monthly downloads on npm)
html5-qrcode — Browser-based QR scanning (5M+ monthly downloads)
express + multer — Backend and file handling
jsonwebtoken — Guest authentication tokens
Vanilla JS — No framework, deliberately

Key Takeaways

QR codes are underrated infrastructure. They're free, universally supported, and bridge the physical-digital gap better than anything else.
The browser camera API is production-ready — if you handle the edge cases. Test on real devices, not just Chrome DevTools device emulation.
"No app" is a superpower. The conversion rate from "sees QR code" to "uploads photo" was over 80%. Compare that to app install funnels.
Compress on the client, store on the server, purge on a schedule. This simple data flow eliminated 90% of the complexity I initially over-engineered.
Build for the least technical user. If a 78-year-old grandmother can use it, your UX is right.

If you're building something similar, start with a single HTML file that opens the camera and uploads to a basic endpoint. You'll have a working prototype in an afternoon. Everything else — the QR codes, the event management, the gallery view — is just polish on top of that core loop.

Have you built something with QR codes or the browser camera API? I'd love to hear about your experience in the comments.