DEV Community: ArtiDigital

Why I Open-Sourced My QR Code Generator

ArtiDigital — Fri, 04 Sep 2026 00:13:48 +0000

Why I Open-Sourced My QR Code Generator (And What It Taught Me About Marketing)

Quick Answer: I open-sourced a QR code generator I built for a client project and it became my most effective marketing tool. Within six months, it generated more qualified leads than a year of paid advertising. The lesson? Developer trust is the most valuable currency in technical marketing, and building in public creates that trust faster than any traditional campaign.

Introduction: The Accidental Marketing Experiment

Two years ago, I built a QR code generator for a client who needed custom-branded codes with logo embedding for their product packaging. The project was straightforward on paper: take a URL, encode it using Reed-Solomon error correction, overlay a logo in the center while maintaining sufficient error correction capacity, and output a PNG file suitable for print.

I used the qrcode npm package, which enjoys 82 million monthly downloads, and added a canvas-based logo overlay with automatic error correction level adjustment. The entire implementation took about three days. When the client project wrapped and the invoice was paid, I faced a familiar dilemma.

Most developers have dozens of these small utilities sitting in private repositories—functional, tested, but invisible. I had two choices: let the code gather dust, or clean it up and release it to the world. I chose the latter, mostly out of curiosity. I had zero marketing budget, no Twitter following to speak of, and no plan.

I had no idea that decision would reshape how I thought about marketing technical products.

Why QR Code Generators Matter More Than You Think

Before diving into the marketing lessons, let us understand why QR codes are such an interesting case study. The global QR code labels market is projected to reach $2.3 billion by 2027, driven by contactless payment adoption, digital menu proliferation, and supply chain digitization.

Yet the developer tooling landscape for QR codes is oddly fragmented. On one end, you have basic online generators that produce plain black-and-white codes with no customization. On the other, you have enterprise SaaS platforms charging $49 per month for features like logo embedding and batch generation. The middle ground—developer-friendly, customizable, free tools with no signup gates—was surprisingly empty.

This market gap validated my decision. The demand was proven. The supply was inadequate. I just needed to execute and make the tool discoverable.

What Happened After I Hit the Publish Button

I spent one evening polishing the repository. I wrote a README that told a story, not just documented an API. I deployed a live demo to GitHub Pages. I wrote one dev.to article about the architecture choices and posted it to r/webdev and r/javascript. Total time invested: about six hours. Total marketing budget: zero dollars.

The results surprised me:

Within 48 hours: 200 GitHub stars
Within one month: 1,500 stars, 10,000 demo site visitors
Within six months: 8,000 stars, 50,000 monthly visitors, 47 contributors The GitHub traffic graph looked like a hockey stick. But here is what really caught my attention: the traffic was not from Hacker News front page fame or viral tweets. It was organic search. Developers were finding the repository by searching for exactly what it did.

The Qualified Lead Problem

Here is what traditional marketing gets wrong about developer audiences. When you run Google Ads for "QR code generator API," you attract everyone: curious students, price shoppers, enterprise procurement teams doing research, and competitors scraping your pricing page. Your cost per qualified lead is high because your targeting is broad.

Open source operates differently. The person who finds your GitHub repository, reads your README, and clones your code is already qualified. They have a specific problem. They are evaluating technical solutions. They are reading your actual implementation to judge your competence. This is the most pre-qualified audience in software marketing.

The Three-Phase Open Source Marketing Flywheel

Over six months, I observed a repeatable pattern that I now call the open source marketing flywheel. It has three distinct phases, each building momentum for the next.

Phase 1: Discoverability Through Developer Search

GitHub is the second most popular search engine for developers after Google. When someone searches "qr code generator javascript," "custom qr code with logo npm," or "vanilla javascript qr code library," they often land on GitHub repositories before they find blog posts or SaaS landing pages.

My repository ranked well for these queries because I applied the same semantic SEO principles I would use on a blog post. The repository description included exact phrases developers search for: "QR code API," "logo embedding," "error correction levels," "batch generation," and "vanilla JavaScript." The README used these terms naturally in context.

GitHub's search algorithm considers README content, description keywords, star velocity, and issue activity. By treating the repository as a search-optimized landing page, I improved discoverability without spending on ads.

[Internal link: related article on GitHub SEO and repository optimization strategies]

Phase 2: Trust Through Transparency

Developers are naturally skeptical of marketing claims. They have been sold too many tools that promise simplicity and deliver frustration. The open source model bypasses this skepticism entirely because the proof is right there in the repository.

When someone can inspect your implementation, see how you handle edge cases, verify you are not collecting their data, and check that your dependencies are reasonable, they trust you in a way that no testimonial or case study can replicate.

I made several trust-building decisions explicit in the README:

Zero server dependencies: the tool runs entirely in the browser
No data collection: QR codes are generated client-side, URLs never leave the user's device
No API keys required: no signup, no rate limits, no surprise bills
Small dependency tree: only the battle-tested qrcode package These features became the most cited reasons users chose my generator over competitors. Trust was not claimed; it was demonstrated through architecture.

Phase 3: Community as Distribution Channel

The most valuable feature I added was not technical at all. It was a clear "Contributing" section in the README that invited pull requests and explained how to set up a development environment in three commands.

Within three months, the community had added capabilities I never planned:

SVG output support for infinite scalability
React and Vue wrapper components for framework integration
Batch generation for processing multiple URLs at once
Color gradient fills instead of solid black modules
Webcam QR code scanning using MediaDevices.getUserMedia() Each contributor became an advocate. They tweeted about their additions. They wrote their own blog posts. They recommended the tool to their networks. Some brought their companies' engineering teams into the fold. The community became an unpaid, enthusiastic marketing department.

This is the compounding effect that traditional marketing cannot replicate. Your contributors' networks are pre-qualified developer audiences, and their recommendations carry more weight than any ad.

Common Mistakes When Using Open Source as Marketing

Not every open-source project becomes a lead generator. I analyzed 50 developer-focused repositories with over 1,000 stars to understand what separated successful marketing tools from abandoned code dumps. The successful ones avoided these specific mistakes.

Mistake 1: Treating Documentation as an Afterthought

A README is not documentation. It is a landing page for developers. The repositories that converted visitors into users had READMEs that followed a specific structure:

A one-sentence description at the top that answers "what is this and why should I care?"
A live demo link within the first 100 words
Installation instructions that work on copy-paste without modification
A "Why this exists" section that tells a story and establishes credibility
Usage examples that solve real problems, not just show API syntax Repositories that skipped the story and jumped straight into API documentation had higher star counts from casual browsers but lower conversion to actual users. Stars do not pay bills. Usage does.

Mistake 2: No Clear Bridge Between Free and Paid

Some developers open-source everything and hope the business outcomes will magically materialize. This is a lottery strategy. The projects that generated real business value had a clear, logical connection between the open tool and a paid service.

In my case, the free QR code generator demonstrated specific expertise:

Canvas manipulation and image processing
QR code error correction algorithms and capacity planning
Developer tooling UX and API design
Zero-dependency architecture for privacy-sensitive environments These are exactly the capabilities that clients pay premium rates for. The open-source project was a portfolio piece that scaled infinitely. Every user who integrated it into their workflow was implicitly validating my skills for future consulting engagements.

[Internal link: related article on building a developer consulting pipeline from open source projects]

Mistake 3: Passive Maintenance and Poor Community Engagement

GitHub is not Dropbox with version control. It is a social network for developers. The repositories that thrived had active maintainers who responded to issues within 24 hours, merged pull requests within a week, and participated in discussions with genuine curiosity.

I invested approximately 30 minutes per day on issue triage and pull request review during the first three months. That investment paid dividends in community goodwill, word-of-mouth referrals, and the surprising benefit of free quality assurance from users who cared enough to report bugs.

Passive repositories—those with unanswered issues from six months ago and stale READMEs—signal abandonment. Active repositories signal reliability. In technical marketing, reliability is the brand.

Building in Public: The Psychology of Developer Trust

Building in public is not merely about sharing code. It is about strategic vulnerability. When you publish your work before it is perfect, you invite feedback, criticism, and collaboration. That feedback loop creates better products and, more importantly, stronger human relationships with your users.

Developers resonate with authenticity in a way that surprises traditional marketers. A polished landing page with perfect typography and stock photography says "we are a corporation." A GitHub repository with 47 open issues, a half-finished feature branch, and a maintainer who admits "I do not know the best approach to that yet, what do you think?" says "we are human, and we are figuring this out together."

The QR code generator had bugs at launch. I fixed them in public. I wrote about the fixes in the repository discussions. I thanked contributors by name in the release notes. That transparency turned casual users into invested community members, and community members into customers who trusted me with their projects.

Technical Architecture That Enabled the Strategy

For the technical readers considering a similar approach, here is the stack that made this zero-infrastructure project possible:

Core encoding: The qrcode npm package (82 million monthly downloads) for reliable QR code generation
Canvas rendering: HTML5 Canvas API for logo overlay, styling, and PNG export
Scanning capability: MediaDevices.getUserMedia() for webcam QR scanning, added later by a contributor
Build system: Vite for fast bundling with zero configuration
Demo hosting: GitHub Pages, free and directly integrated with the repository
Testing: GitHub Actions for automated CI on every pull request Total infrastructure cost: zero dollars. The only investment was time and attention.

Key Takeaways

Open source is fundamentally a trust-building mechanism, not merely a code distribution method.
Developer marketing succeeds when you show competence through code, not claim it through copy.
A well-documented, focused utility can generate more qualified leads than expensive advertising campaigns targeting broad audiences.
Community contributions multiply your reach and capability without proportionally increasing your workload.
Transparency and authentic communication outperform polished marketing copy for technical audiences.
GitHub SEO matters: keywords, README structure, and engagement signals directly affect discoverability.
The most effective open-source marketing projects create a clear bridge between the free tool and paid professional services.
Consistent maintenance and genuine community engagement compound over time into sustainable business advantages.
Developer trust, once earned, converts at higher rates than any other marketing channel in technical software.

Frequently Asked Questions

Does open-sourcing a tool really generate business leads?

Yes. My QR code generator generated more qualified leads in six months than a year of paid advertising. Open-source users self-select as people with a specific problem you can solve, and they already trust your code before they ever contact you.

How do I choose which project to open-source?

Select a project that solves a problem you have already solved for paying clients. It should demonstrate expertise in services you want to sell more of.

What if someone copies my code and becomes a competitor?

Execution and community matter far more than raw code. A fork without your ongoing expertise and continuous development is a hollow imitation.

How much time does maintaining an open-source project require?

Budget 30 minutes daily during active growth phases. After the initial burst, maintenance drops to 1-2 hours weekly. Automate testing with GitHub Actions.

Should I open-source my entire product or begin with a utility?

Start with a focused utility. Open-sourcing your entire product is a complex strategic decision. A small tool lets you test the strategy with minimal risk.

Does the software license choice affect marketing outcomes?

Yes. Permissive licenses like MIT and Apache 2.0 maximize adoption. Copyleft licenses like GPL can deter enterprise users.

How do I convert open-source users into paying customers?

Add a clear Hire Me or Enterprise Features section in your README. Write blog posts about advanced use cases. Be genuinely helpful in discussions.

What platforms work best for building in public?

GitHub serves as your technical landing page. Dev.to and Twitter are ideal for narrative. Reddit and Hacker News provide distribution to qualified audiences.

Do I need an established personal brand to succeed?

No. I had fewer than 500 Twitter followers when I published. The project grew because it solved a real problem. Quality work finds its audience.

How long before an open-source project generates meaningful business leads?

My first qualified inquiry arrived three weeks after publication. Most well-documented projects see traction within two to three months.

Conclusion

Open-sourcing my QR code generator was not a calculated marketing strategy when I started. It was a simple experiment born from curiosity. But it taught me the most valuable lesson in technical marketing: the most effective way to sell to developers is not through advertising, but through demonstrated competence and earned trust.

Every commit you push, every issue you respond to, every pull request you merge is a deposit in your trust bank account. That trust compounds over time into the most valuable asset any technical business can own: a reputation for reliability and expertise.

If you have a project sitting in a private repository right now, consider the potential cost of keeping it hidden. The worst case is that no one discovers it. The best case is that it becomes your most valuable marketing asset, a lead generation engine that works while you sleep, and a community of advocates who sell your expertise for you.

Start small. Start with something useful. Start today. The developer community is waiting, and they are searching for exactly what you have already built.

Want to see the QR code generator in action? Check out our homepage for live demos and comprehensive documentation. For more developer tooling insights, explore our developer tools sitemap and open source guides.

Processing 10,000+ Wedding Photos: My Image Pipeline

ArtiDigital — Tue, 01 Sep 2026 00:09:48 +0000

Processing 10,000+ Wedding Photos: My Image Pipeline Architecture

Quick Answer: A scalable image pipeline for wedding photography uses asynchronous job queues, multi-format conversion (WebP/AVIF), intelligent thumbnail generation, and CDN edge caching to process 10,000+ photos efficiently while maintaining visual quality and fast delivery.

Introduction

Wedding photography generates massive amounts of image data. A single wedding with two photographers can easily produce 5,000–10,000 RAW files. When I built WedPlanner, a platform for wedding vendors, I quickly realized that naively uploading full-resolution JPEGs to S3 wasn't going to cut it.

Photographers needed fast gallery previews. Couples wanted to share images instantly. And mobile users on 3G connections couldn't wait for 15MB files to load. The challenge wasn't just storage—it was building a pipeline that could process, optimize, and deliver images at scale without breaking the budget or the user experience.

This is the architecture I ended up with, built in public over six months of iteration.

Why Image Processing at Scale Is Hard

Before diving into the solution, let's understand the problem. Wedding photos present unique challenges:

Volume: 3,000–15,000 images per event
Resolution: 24MP–45MP cameras produce enormous files
Formats: RAW, JPEG, HEIC, and now JPEG XL
Use cases: Full-resolution downloads, web galleries, thumbnails, social sharing
Latency expectations: Users expect galleries to load in under 2 seconds Traditional approaches like processing images synchronously during upload fail spectacularly at this scale. Uploading 10,000 images and waiting for each to process before showing a confirmation screen? That's a recipe for timeouts and abandoned uploads.

The Pipeline Architecture

My pipeline follows a fan-out pattern with four distinct stages:

Stage 1: Upload Buffer

Images land in a temporary S3 bucket via presigned URLs. This decouples upload from processing and lets photographers start uploading immediately. No waiting, no blocking. The client gets an instant "Upload complete" message while the heavy lifting happens asynchronously.

I use S3 multipart uploads for files over 5MB, which dramatically improves reliability on flaky connections—essential when photographers upload from venue Wi-Fi.

Stage 2: Queue and Fan-Out

Once uploaded, a Lambda function triggers from S3 event notifications and drops a message into an SQS queue. From there, the work fans out to multiple parallel processors:

Thumbnail generator: Creates 5 sizes (150px, 300px, 600px, 1200px, 2000px wide)
Format converter: Generates WebP and AVIF variants for each size
Metadata extractor: Pulls EXIF data (camera settings, GPS, timestamps)
Duplicate detector: Uses perceptual hashing (pHash) to catch burst-mode duplicates This fan-out pattern is critical. Processing 10,000 images sequentially would take hours. Running each image through four parallel jobs reduces total processing time to roughly 20–30 minutes.

Stage 3: Optimization Strategy

Raw JPEGs from professional cameras are surprisingly unoptimized. I apply several techniques:

Progressive JPEG encoding: Loads a low-resolution preview first, then fills in detail. Essential for perceived performance.

Chroma subsampling 4:2:0: Reduces file size by ~30% with minimal visual impact on web viewing.

MozJPEG: Facebook's JPEG encoder produces files 10–20% smaller than standard libjpeg at the same quality. For galleries viewed on phones and laptops, quality 85 with MozJPEG hits the sweet spot.

WebP and AVIF: These modern formats deliver 25–50% smaller files than JPEG. I generate both and serve them via content negotiation—the browser requests what it supports.

Here's a real comparison from our production pipeline:

FormatAverage Size (24MP)QualityBrowser SupportJPEG (baseline)8.2 MB85UniversalJPEG (MozJPEG)6.1 MB85UniversalWebP4.3 MB8594%+AVIF3.1 MB8085%+The AVIF savings are real, but encoding is CPU-intensive—about 4x slower than WebP. I generate AVIF asynchronously and serve it as a progressive enhancement.

Stage 4: CDN and Intelligent Delivery

All processed images live in a final S3 bucket with CloudFront in front. But CDN alone isn't enough—you need smart delivery logic.

I built a small Node.js service that acts as an image origin. It handles:

Content negotiation: Inspects Accept headers to serve WebP/AVIF when supported
Responsive sizing: Uses URL parameters (?w=600) to serve the closest pre-generated size
Client hints: DPR and Width hints from supported browsers eliminate guesswork
Lazy loading prep: Generates blurhash placeholders for instant visual feedback Blurhash is particularly effective for wedding galleries. Users see a colorful approximation of the image immediately while the full version loads. It feels instant even on slow connections.

Storage Strategy and Cost Control

Storing 10,000 wedding photos across multiple formats gets expensive fast. My tiered approach:

Hot storage (S3 Standard): Original RAWs and active gallery images for 90 days
Warm storage (S3 Intelligent-Tiering): Frequently accessed thumbnails and medium sizes
Cold storage (S3 Glacier): Originals after 90 days, accessible within minutes For a typical 8,000-image wedding, this breaks down to roughly:

RAW files ( backup only): ~120 GB → Glacier after 90 days
Full-resolution JPEGs: ~40 GB → Standard for 90 days
Thumbnails and web sizes: ~15 GB → Intelligent-Tiering
CDN cache: ~50% hit rate, reducing origin requests significantly Total first-month storage cost: approximately $12–18 per wedding. After 90 days, that drops to under $5 with Glacier.

Thumbnails: The Secret Performance Weapon

Thumbnails are where most image pipelines fall short. Serving a 2,000px wide image when the user only needs 300px wastes bandwidth and kills perceived performance.

My thumbnail strategy generates five sizes at upload time:

Micro (150px): Grid previews, fast initial render
Small (300px): Mobile gallery view
Medium (600px): Tablet and desktop thumbnails
Large (1200px): Lightbox preview
XLarge (2000px): Full-screen viewing, retina displays I use the <picture> element with srcset to let browsers choose the optimal size. This single change improved our Lighthouse performance score from 62 to 94.

One subtle optimization: thumbnail sharpening. Downsampling destroys fine detail. Applying unsharp mask during resize (radius 0.3, amount 80%) keeps edges crisp without looking artificial.

Common Mistakes I Made (So You Don't Have To)

Mistake 1: Processing during upload

My first iteration processed images synchronously. A photographer uploading 500 images would stare at a progress bar for 20 minutes. Users hated it. Moving to async queue processing was the single biggest UX improvement.

Mistake 2: Ignoring memory limits

Sharp (the Node.js image library I use) loads entire images into memory. Processing a 45MP RAW requires 200+ MB per image. Running 50 concurrent Lambda functions caused OOM kills. I now cap concurrency at CPU cores × 2 and use streams where possible.

Mistake 3: Forgetting about color profiles

Professional photographers use Adobe RGB or ProPhoto RGB. Serving these to web browsers without conversion to sRGB causes washed-out colors on most displays. Always convert to sRGB for web delivery—photographers will notice if you don't.

Mistake 4: Not handling orientation metadata

iPhone photos store orientation in EXIF rather than actually rotating pixels. Libraries like Sharp handle this automatically, but forgetting to check caused some of our early thumbnails to appear sideways. Always read and apply EXIF orientation.

Technology Stack

Here's what actually powers this pipeline:

Sharp (libvips): Fast Node.js image processing. Handles resize, format conversion, and optimization.
AWS Lambda + SQS: Event-driven processing with automatic scaling.
S3 + CloudFront: Storage and CDN with custom origin logic.
Redis: Job status tracking and deduplication.
PostgreSQL: Image metadata and gallery organization. Sharp is the workhorse here. It's approximately 4x faster than ImageMagick for typical resize operations and has excellent memory efficiency. The npm package sees over 3 million weekly downloads, which speaks to its reliability.

Performance Results

After implementing this pipeline, our metrics improved dramatically:

Gallery load time: 8.2s → 1.4s (mobile, 3G)
Time to first image visible: 4.1s → 0.3s (blurhash)
Storage cost per wedding: $45 → $12 (first month)
Upload completion rate: 73% → 97%
CDN hit ratio: 67% (warm cache), 89% (after 24 hours) Most importantly, photographer churn dropped by 40%. When the tool actually works reliably, people stick around.

Key Takeaways

Process images asynchronously using job queues—never block uploads with synchronous processing
Generate multiple sizes and formats upfront; content negotiation at delivery time eliminates waste
Use blurhash placeholders for instant perceived performance on slow connections
Tier your storage strategy: hot for active content, cold for archives
Always convert color profiles to sRGB and respect EXIF orientation for web delivery
Monitor memory usage carefully; image processing is memory-intensive and can crash servers
Sharp + AWS Lambda provides a cost-effective, scalable foundation for image pipelines
Thumbnails are not optional—invest in multiple sizes and responsive image markup

Frequently Asked Questions

How long does it take to process 10,000 wedding photos?

With parallel processing across multiple Lambda workers, a typical pipeline processes 10,000 images in 20–30 minutes. This depends on how many sizes and formats you generate. Generating only JPEG thumbnails takes 10–15 minutes; adding WebP, AVIF, and EXIF extraction extends this.

What's the best image format for web galleries?

AVIF offers the best compression (25–50% smaller than JPEG), but WebP has broader browser support and faster encoding. The practical answer: serve WebP as your primary format with JPEG fallback, and add AVIF as progressive enhancement for supported browsers.

How much does image processing infrastructure cost?

For 10,000 images per wedding with 5 thumbnail sizes and 2 formats, expect roughly $12–18 in storage costs during the first 90 days. Processing costs via AWS Lambda range from $5–15 per wedding depending on concurrency settings. CDN costs add $3–8 for typical gallery traffic.

Should I store RAW files or just JPEGs?

Store RAW files if photographers require them for re-editing, but move them to cold storage immediately. Most wedding photography platforms only need JPEGs for gallery delivery. RAW files are 3–5x larger and unnecessary for web viewing.

What's the difference between Sharp and ImageMagick?

Sharp uses libvips under the hood and is significantly faster (up to 4x) with lower memory usage than ImageMagick. Sharp also has a simpler API and better Node.js integration. ImageMagick supports more obscure formats, but for standard web processing, Sharp is the better choice.

How do you handle duplicate photos from burst mode?

I use perceptual hashing (pHash) to generate a fingerprint for each image. Images with similar hashes are flagged as potential duplicates. For burst-mode shots, I keep the sharpest image (determined by variance of Laplacian) and offer the rest as a "similar photos" group.

Is JPEG XL worth implementing?

Not yet. JPEG XL offers excellent compression but lacks browser support (only Safari as of 2026). Until Chrome and Firefox add support, stick with WebP and AVIF. Monitor caniuse.com for JPEG XL adoption.

How do you prevent storage costs from growing forever?

Implement lifecycle policies: delete thumbnails after galleries expire, archive originals to Glacier after 90 days, and use S3 Intelligent-Tiering for unpredictable access patterns. Most wedding photos see 80% of their lifetime views in the first 30 days.

What's the ideal thumbnail size for wedding galleries?

Generate at least five sizes: 150px for grids, 300px for mobile, 600px for tablets, 1200px for lightboxes, and 2000px for retina displays. Use responsive images with srcset so browsers download only what they need.

Can this pipeline handle video files too?

This pipeline focuses on images. Video requires different tools (FFmpeg) and much more processing power. If you need video, run a separate pipeline. Mixing video into image queues causes unpredictable processing times and can stall your entire pipeline.

Conclusion

Building an image pipeline that handles 10,000+ wedding photos isn't about finding one magic tool—it's about combining the right pieces with smart architecture decisions. Asynchronous processing, format optimization, intelligent thumbnails, and tiered storage work together to create a system that's fast for users and affordable to operate.

If you're building something similar, start simple. Get uploads working with async processing first. Add formats and optimizations later. The biggest wins come from not blocking users during upload and serving appropriately sized images.

Want to see how this pipeline fits into a complete wedding photography platform? Check out WedPlanner for more backend architecture articles, or browse our photography tips archive and tech stack deep-dives for related reads.

Have questions about image processing at scale? Drop them in the comments—I read every one.

QR Code Architecture: Connecting 200 Guests to One Gallery

ArtiDigital — Fri, 28 Aug 2026 00:15:27 +0000

QR Code Architecture: How One Scan Connects 200 Guests to a Shared Gallery

Quick Answer: A QR code photo sharing system works by encoding a unique session URL into a scannable code. When guests scan it, their browsers join a WebSocket room tied to that session. Uploaded images broadcast to all connected clients instantly, creating a synchronized gallery without apps, accounts, or friction.

Introduction: The Problem with Wedding Photo Sharing

Three weeks ago, I watched a bride spend twenty minutes explaining a photo-sharing app to her grandmother. Download this, create an account, verify your email, join this album, enable notifications. The grandmother nodded politely and took zero photos for the rest of the night.

That friction is the enemy of event photo sharing. When you have 200 guests at a wedding, corporate event, or birthday party, you need a system that works for the tech-savvy niece and the uncle who still uses Internet Explorer. The solution? A single QR code that eliminates every barrier between wanting to share a photo and seeing it in the gallery.

In this post, I will break down the architecture we built to handle 200-plus concurrent guests uploading photos to a shared gallery in real-time. No apps. No accounts. No configuration. Just scan, snap, and sync.

What Is a QR Code Session Architecture?

A QR code session architecture is a pattern where a machine-readable code encodes a URL containing a unique session identifier. Scanning the code opens a web application pre-configured with that session context, eliminating manual input and reducing onboarding friction to near zero.

The architecture has three core components:

Code Generation Layer: Creates QR codes embedding session-specific URLs
Session Management Layer: Tracks active rooms, participant counts, and expiration
Real-Time Sync Layer: Broadcasts uploads to all connected clients instantly

Unlike traditional photo-sharing apps that require account creation and album management, this approach treats the QR code as both the invitation and the authentication mechanism. The session ID in the URL is the only credential needed.

How QR Code Generation Works at Scale

We use the qrcode npm package, which sees 82 million monthly downloads, to generate codes server-side. The key decision is what goes into the code itself.

URL Structure and Session Encoding

Each QR code encodes a URL like:

https://gallery.app/s/abc123def

The /s/ prefix routes to our session handler, and abc123def is a cryptographically random 9-character alphanumeric string. We avoid UUIDs here because they make the QR code denser and harder to scan from a distance or at odd angles.

Error Correction and Scan Reliability

QR codes support four error correction levels: L at 7 percent, M at 15 percent, Q at 25 percent, and H at 30 percent. We use Level M as our default. Here is why: Level H creates larger, denser codes that scan worse from projectors and TV screens at events. Level M gives us 15 percent redundancy, enough to handle a smudged table tent or a wrinkled printed card without sacrificing scan speed.

Generation Pipeline

When an event organizer creates a gallery, our backend performs five steps:

Generates a unique session ID
Creates the session record in PostgreSQL with a 48-hour TTL
Generates the QR code SVG with qrcode.toString()
Uploads the SVG to our CDN for fast global delivery
Returns the gallery URL and QR code URL to the organizer

The whole pipeline completes in under 200 milliseconds. Organizers get a shareable link and a printable QR code instantly.

Session Management: Handling 200 Concurrent Guests

Session management is where most QR code projects fail. A wedding is not a controlled environment. Guests arrive in bursts. Some stay connected for hours. Others scan the code, upload one photo, and close their browser.

WebSocket Room Architecture

We use Socket.IO, not raw WebSockets, for the sync layer because it handles fallbacks gracefully. If a guest corporate network blocks WebSockets, Socket.IO falls back to HTTP long-polling automatically.

Each session ID maps to a Socket.IO room. When a guest scans the QR code, four things happen:

Browser loads the gallery page
Socket.IO client connects to our server
Server calls socket.join(sessionId)
Server emits the current gallery state, the last 50 images, to that socket

The guest is now in sync with everyone else in the room.

Participant Counting and Limits

We track active connections per room using a Redis-backed counter. When a socket connects, we increment. When it disconnects, including on browser close, tab switch, or network drop, we decrement. This gives us real-time visibility into room occupancy.

Our soft limit is 250 concurrent connections per room. In practice, weddings rarely exceed 150 simultaneous uploaders because guests are eating, dancing, or talking, not constantly on their phones. The 250 limit is a safety rail, not a bottleneck.

Session Lifecycle and Cleanup

Sessions expire 48 hours after creation by default. We use Redis TTLs for automatic cleanup of active room data, and a nightly cron job archives uploaded images to cold storage before deleting the PostgreSQL session record.

This prevents abandoned sessions from consuming resources indefinitely. An organizer can extend a session manually, but the default expiration protects us from the set-it-and-forget-it problem.

Real-Time Gallery Synchronization

The magic happens when guest number 47 uploads a photo and guests number 3, 12, and 200 see it appear on their screen without refreshing.

The Upload and Broadcast Flow

When a guest selects a photo, the following occurs:

Client resizes the image to 1200px width using Canvas API, reducing upload size by about 70 percent
Client generates a client-side UUID for the image
Image uploads to our presigned S3 URL
On upload completion, client emits image:uploaded with the UUID and S3 key
Server validates the session, stores metadata in PostgreSQL
Server broadcasts image:new to all sockets in the room
All connected clients append the image to their gallery DOM

Total latency from upload to broadcast is typically 300 to 800 milliseconds depending on image size and network conditions.

Handling Race Conditions

What if two guests upload simultaneously? Socket.IO processes events sequentially per room, so we do not get interleaved broadcasts. Each image:new event carries a server-assigned sequence number, and clients sort their galleries by this number. This guarantees consistent ordering across all devices regardless of network latency differences.

Offline Resilience

If a guest loses connection mid-upload, our client-side queue retries the upload automatically when connectivity returns. The client-side UUID prevents duplicate entries if the upload actually succeeded but the acknowledgement was lost.

Security Considerations for Open Galleries

An open QR code gallery has no passwords, no accounts, and no invite lists. That simplicity is the feature, but it also means we need other protections.

Rate Limiting by Session

Each session is rate-limited to 10 uploads per IP per minute. This stops a single guest from flooding the gallery without impacting anyone else experience. The limit is generous: 600 uploads per hour per person, which covers even the most enthusiastic photographer.

Content Moderation Pipeline

Every uploaded image passes through AWS Rekognition for content moderation. Inappropriate content is flagged and hidden from the gallery within 2 to 3 seconds of upload. Event organizers can review flagged content in a moderation dashboard, but guests never see it.

Session URL Obscurity

Our 9-character session IDs provide 52 bits of entropy. Brute-forcing a valid session ID is computationally infeasible during the 48-hour session lifetime. We do not rely on obscurity alone, it is one layer in a defense that includes rate limiting and moderation, but it means random scanning attacks will not find active galleries.

Performance Optimizations for 200 Plus Guests

Scaling to 200 concurrent users on a single gallery is not trivial. Here is what we learned:

Image Delivery: CDN and Lazy Loading

We serve images through CloudFront with aggressive caching. Thumbnails are generated at upload time, 300px width, for gallery grids, and full-resolution images load on click. This means 200 guests scrolling through a gallery are not hammering our origin server, they are hitting edge caches for tiny thumbnails.

Socket.IO Adapter Sharding

On our multi-node deployment, Socket.IO uses Redis as the adapter to broadcast events across server instances. Without this, guests connected to Server A would not see uploads from guests on Server B. The Redis adapter ensures room-wide broadcasts work regardless of which server handles the connection.

Database Query Optimization

Our gallery metadata queries use a composite index on session_id and created_at. With 200 guests uploading 5 photos each, that is 1000 rows per event. Even without pagination, PostgreSQL serves the full gallery state in under 5 milliseconds.

Common Mistakes When Building QR Code Systems

We made these mistakes so you do not have to:

Using UUIDs in QR codes: UUIDs create dense codes that scan poorly at distance. Use shorter, random alphanumeric strings.
Storing images in the database: Binary image data bloats PostgreSQL and slows backups. Use object storage like S3 with metadata references.
Ignoring WebSocket fallbacks: Corporate firewalls block WebSockets. Always implement HTTP fallback or use Socket.IO.
Client-side image resizing with CSS: Resizing with CSS still uploads the full-resolution file. Use Canvas API to resize before upload.
No expiration on sessions: Abandoned galleries accumulate forever. Always implement automatic cleanup.

Key Takeaways

A QR code session architecture encodes a unique URL that eliminates app downloads, accounts, and configuration for end users.
Error correction Level M balances scan reliability with code density for projector and print display.
Socket.IO rooms with Redis adapter enable real-time synchronization across multiple server nodes.
Client-side image resizing, CDN delivery, and thumbnail generation keep performance acceptable at 200 plus concurrent users.
Rate limiting, content moderation, and session expiration are essential for open, unauthenticated galleries.
Sequence numbers on broadcast events guarantee consistent gallery ordering across all connected devices.

Frequently Asked Questions

How many guests can connect to one QR code gallery simultaneously?

Our architecture supports 250 concurrent connections per gallery room. In practice, event activity patterns mean 150 to 200 simultaneous active users is typical, with brief spikes during key moments like cake cutting or first dances.

What happens if a guest loses internet connection during upload?

The client queues the upload and retries automatically when connectivity returns. Client-side UUIDs prevent duplicate entries if the upload succeeded but the acknowledgement was lost.

Do guests need to download an app or create an account?

No. The entire system works in a mobile browser. Scanning the QR code opens a web page where guests can immediately view and upload photos without registration.

How long are galleries and photos stored?

Default session lifetime is 48 hours. Organizers can extend this manually. After expiration, photos are archived to cold storage for 30 days before permanent deletion unless the organizer downloads them.

What image formats and sizes are supported?

We accept JPEG, PNG, and HEIC, converted to JPEG on upload. Client-side resizing reduces all images to 1200px width before upload. Maximum file size after resizing is approximately 800 kilobytes.

Can galleries be password-protected?

Yes, though we default to open galleries for maximum accessibility. Password protection can be enabled in the organizer dashboard, adding a 4-digit PIN that guests enter after scanning.

How does the system handle simultaneous uploads from multiple guests?

Socket.IO processes events sequentially per room. Each upload receives a server-assigned sequence number, and clients sort galleries by this number for consistent ordering regardless of network latency.

What QR code scanning libraries work best for this pattern?

We recommend html5-qrcode, which sees 5 million monthly downloads, for browser-based scanning. It supports camera selection, torch control, and falls back gracefully on older devices.

Is the gallery accessible on older phones?

Yes. The gallery interface uses progressive enhancement. Core functionality works on any device with a camera and a modern browser. Advanced features like real-time sync degrade gracefully if WebSockets are unavailable.

How much does it cost to run this architecture?

At our scale of hundreds of events per month, infrastructure costs run approximately 15 cents per event for compute, storage, and CDN. A single wedding with 200 guests and 1000 photos costs less than a cup of coffee to serve.

Conclusion

Building a QR code photo sharing system taught me that the best user experience is often the one with the fewest steps. No apps. No accounts. No friction. Just a code, a camera, and a gallery that updates in real-time.

The architecture is not magic. It is WebSockets, Redis, presigned S3 URLs, and some careful attention to error correction levels. But the result feels like magic to a grandmother who scans a code and sees her grandson wedding photos appear on her screen seconds after they are taken.

If you are building something similar, start with the session management layer. Everything else, QR codes, uploads, sync, depends on getting that right. And remember: the simplest interface for your users often requires the most thoughtful engineering underneath.

Building in public is how we learn. If you found this useful, check out our homepage for more technical deep-dives, or explore our article archive and project index for related work.

From Side Project to 12,000+ Events: Lessons From Building a Wedding Tech Product

ArtiDigital — Fri, 21 Aug 2026 00:13:02 +0000

A few years ago, I built a wedding planning tool as a side project to scratch my own itch. It was ugly, buggy, and barely functional. Today, that same tool has powered over 12,000 wedding events. Here's what I learned along the way — the pivots, the mistakes, and the moments that changed everything.

How It Started: A Scrappy MVP

My friend was planning her wedding and kept complaining about how scattered everything was — guest lists in spreadsheets, RSVPs in her inbox, a seating chart on graph paper. As a developer, my instinct was obvious: build something.

The first version was a single-page app built with React and Firebase. It did exactly three things:

Created a guest list with import from CSV
Sent RSVP links via email
Showed a simple table arrangement view No auth beyond a magic link. No mobile app. No payment integration. Just a tool that solved one problem slightly better than a Google Sheet. I shipped it in a weekend and shared it in a wedding planning Facebook group. Within 48 hours, 30 couples had signed up.

The First Pivot: From Tool to Platform

Those 30 users gave me something invaluable: signal. The RSVP feature got used constantly. The seating chart? Almost nobody touched it. But I started getting messages asking for things I hadn't considered:

Can guests select meal preferences?
Can we send reminders to people who haven't responded?
Can we embed this on our wedding website? That last question was the lightbulb moment. These couples didn't just want a tool — they wanted something that lived alongside their wedding website. So I pivoted. Instead of being a standalone RSVP app, I became an embeddable widget platform that wedding websites could integrate.

Listening to Users: The Feedback Loop That Drove Growth

Here's the single most important thing I did: I talked to every single user in the first 500 signups. Not a survey. Not an email. A 15-minute phone call or chat. I asked three questions:

What were you doing right before you signed up?
What almost stopped you from signing up?
What's the one thing you wish this did? The answers reshaped the product. The first question told me where to focus marketing. The second revealed friction in onboarding (the magic link confused people — they thought it was spam). The third became my backlog.

I built a wedding planning platform around those conversations. Every feature I shipped came from a real user need, not a competitor analysis or a trendy tech blog.

The Technical Decisions That Mattered

A few engineering choices paid off disproportionately:

Going with Firebase early. Real-time sync was a table-stakes feature for couples planning together. Firebase gave me that for free, and I didn't have to build a websocket infrastructure on day one.

Embeddable widgets over a monolithic app. After the pivot, I designed the RSVP and guest management features as embeddable JavaScript widgets. This meant couples could drop them into any wedding website — whether they built it on my platform or elsewhere. This opened up a distribution channel I never could have built intentionally.

Keeping it lean. I resisted the urge to build a mobile app for the first two years. A responsive PWA was 80% as good and took 10% of the effort. The resources I saved went into core features that actually moved retention.

Growth: How We Got to 12,000 Events

There was no viral explosion. No Product Hunt spike that changed everything. Growth was steady and came from three channels:

1. SEO from wedding-specific long-tail keywords. I wrote content targeting queries like "how to collect RSVPs online" and "wedding guest list manager free." These weren't glamorous, but they converted. Organic search became the primary acquisition channel within six months.

2. Word of mouth from couples. Wedding planning is inherently social. Couples share tools with their bridal parties, and those people are often planning their own weddings within a year. Every happy user was a multi-user acquisition channel.

3. Integration partnerships. Once the embeddable widgets were solid, I reached out to wedding website builders and template marketplaces. Three of them bundled my widgets into their templates. That partnership alone drove thousands of signups.

You can explore the full range of planning tools and templates across our resource directory.

The Hardest Lesson: Knowing What NOT to Build

The biggest temptation as an indie hacker is building everything. Every user request feels urgent. Every competitor feature feels like a gap. Here's what I learned:

Say no to features that serve one user. If one person asks for it, note it. If five people ask for it, consider it. If twenty people ask for it, build it.

I wasted three weeks building a vendor coordination module because one user asked for it enthusiastically. Zero other couples used it. That three weeks could have gone into improving the RSVP flow, which affected every single user.

Feature creep kills momentum. Every new feature adds maintenance burden, UI complexity, and support load. The products that win aren't the ones with the most features — they're the ones that do the core job exceptionally well.

What I'd Do Differently

If I were starting over today, here's what I'd change:

Charge from day one. I was free for the first year. It attracted tire-kickers and made it impossible to measure real commitment. A $9 price tag would have filtered serious users and given me revenue feedback sooner.
Build analytics in from the start. I flew blind for months. I didn't know which features were used, where users dropped off, or what the activation moment was. Event tracking from week one would have saved months of guessing.
Niche down harder. "Wedding planning" is broad. I should have picked one segment — maybe outdoor weddings, or budget-conscious couples — and dominated it before expanding.

The Takeaway

Building a wedding tech product taught me that the best growth strategy is a product that solves a real pain point really well. Not growth hacking. Not viral loops. Just a tool that works, users who love it, and the patience to keep improving.

12,000 events later, the lesson is simple: listen to your users, ship fast, say no often, and stay scrappy. The side project didn't become a business because I was clever. It became a business because I paid attention.

If you're building something in a niche space, the playbook is the same. Find one painful problem, solve it better than the alternatives, and let your users guide you from there.

FAQ

How long did it take to reach 12,000 events?

About two and a half years from launch. Growth was steady rather than explosive — roughly 300-400 new events per month in the first year, scaling to 600-800 per month by year two.

What tech stack did you use?

React with Firebase for the MVP, later migrated to Next.js with a Node.js backend and PostgreSQL. The embeddable widgets are vanilla JavaScript wrapped in iframe containers for cross-origin safety.

Did you raise funding?

No. The project was bootstrapped from the start. Revenue from premium subscriptions funded development. I kept costs low by using serverless infrastructure and avoiding unnecessary tooling.

What's the biggest mistake you made?

Staying free for too long. The first year without a pricing model attracted users who weren't committed and gave me noisy feedback. Charging even a small amount would have given me cleaner signal and earlier revenue.

Building a Real-Time Photo Gallery That Handles 500+ Simultaneous Uploads

ArtiDigital — Tue, 18 Aug 2026 00:09:05 +0000

The Problem That Started It All

It started at a hackathon. We built a photo wall — a simple real-time gallery where attendees could upload photos and see them instantly on a big screen. The MVP worked great with 20 people. Then 200 showed up. The server melted. Uploads timed out, the WebSocket connection dropped every few seconds, and the gallery showed more spinners than photos.

That night, I made a decision: I was going to build this properly and document every step. This is that story — the architecture decisions, the dead ends, the unexpected wins, and the final system that handles 500+ simultaneous uploads without breaking a sweat.

Picshots is where this gallery engine ultimately landed — a real-time photo platform that powers live event galleries, community walls, and interactive displays. But the journey to get there was anything but straightforward.

Architecture Overview: What We Built

Here's the high-level architecture we converged on after three iterations:

Upload Gateway: A dedicated Node.js service that accepts multipart uploads, validates them, and enqueues processing jobs — never blocks on image processing.
Message Queue: Redis Streams for job distribution. Each upload becomes a job with a unique ID, priority, and metadata payload.
Worker Pool: Stateless workers (auto-scaled) that consume jobs from Redis, process images (resize, thumbnail, optimize), and upload to object storage.
Real-Time Layer: WebSocket server (Socket.io) that broadcasts gallery updates to connected clients whenever a new photo finishes processing.
Object Storage: S3-compatible storage (we used Cloudflare R2 for egress-cost reasons) for original and processed images.
Database: PostgreSQL for metadata (photo records, gallery state, user associations) with read replicas for the gallery query path. The key insight was separation of concerns: the upload path does nothing but receive and enqueue. The processing path does nothing but transform and store. The delivery path does nothing but query and broadcast. No service in the critical path does more than one thing.

Iteration 1: The Naive Approach (And Why It Failed)

The first version was a single Express server. Upload came in, Multer handled it, Sharp processed it on the same thread, and the result was saved to disk. A Socket.io broadcast told clients to refresh.

At 50 concurrent uploads, response times jumped from 200ms to 8 seconds. At 100, the server was effectively dead — CPU pinned at 100% on image processing, event loop blocked, new connections timing out.

The problem was clear: image processing on the request thread is a death sentence for concurrency. Sharp is fast, but synchronous processing of a 12MB photo (resize, compress, generate thumbnail) takes 150-400ms per image. With 100 uploads hitting simultaneously, that's 15-40 seconds of CPU time queued up with nowhere to go.

Iteration 2: Offloading to a Worker Queue

The second version split the monolith. Uploads went to the Express server, which saved the raw file to a temp directory and pushed a job to Redis. A separate worker process picked up jobs, ran Sharp, uploaded to R2, and updated PostgreSQL.

This was dramatically better — the upload server stayed responsive because it did almost no work. But we hit two new problems:

WebSocket updates were unreliable. The worker finished processing but had no direct connection to the client. We tried having the worker publish to a Redis pub/sub channel that the web server subscribed to, but messages got lost under load.
Single worker bottleneck. One worker process could process maybe 3-4 images per second. At 500 concurrent uploads arriving over 10 seconds, that's a 50-image backlog that takes 12-15 seconds to clear. Acceptable, but not great for a "live" gallery experience. The fix for the WebSocket issue was making the real-time layer its own service. A dedicated Socket.io server with Redis adapter (sticky sessions via Redis for horizontal scaling) subscribed to the job completion channel. When a job finished, the worker published a photo:processed event with the photo ID, gallery ID, and CDN URL. The real-time server pushed it to every connected client in that gallery room.

Event photo galleries on Picshots now use exactly this pattern — each gallery is a Socket.io room, and clients only receive updates for the gallery they're viewing.

Iteration 3: Horizontal Scaling and the 500-Upload Target

To hit 500+ simultaneous uploads, we needed horizontal scaling at every layer. Here's what we did:

Upload Gateway Scaling

We ran 3 instances of the upload gateway behind a round-robin load balancer (nginx with least_conn strategy). Each gateway instance was capped at 200 concurrent connections. With 3 instances, that's 600 concurrent upload slots — headroom above our 500 target.

File size limits mattered more than I expected. We capped uploads at 15MB (rejecting anything larger at the nginx layer before it even hit Node). This prevented a single massive upload from consuming connection time and memory.

Worker Pool Auto-Scaling

Workers were deployed as a Docker Swarm service with auto-scaling rules based on Redis stream length. When the pending job count exceeded 20, a new worker container spun up. When it dropped below 5, workers scaled down. We capped at 8 workers to avoid CPU contention on the host.

Each worker processed one image at a time (Sharp is CPU-bound, so parallelism within a worker doesn't help much). With 8 workers averaging 3 images/second each, that's 24 images/second throughput — enough to clear a 500-image burst in about 21 seconds.

Database Connection Pooling

PostgreSQL connection pooling via PgBouncer was non-negotiable. Without it, each worker and gateway instance opened its own connections, and Postgres choked on 40+ simultaneous connections from a 4GB VPS. PgBouncer in transaction mode kept the actual database connections to 12 while serving 40+ clients.

Real-Time Layer

Two Socket.io server instances with the Redis adapter behind nginx (sticky sessions via ip_hash). Each instance handled up to 5,000 concurrent connections. For a gallery with 500 viewers, this was massive overkill — but it meant the real-time layer would never be the bottleneck.

The Image Processing Pipeline

Here's what happens to each photo once a worker picks it up:

Validation: Verify the file is actually an image (check magic bytes, not just extension). Reject anything that's not JPEG, PNG, or WebP.
Exif stripping: Remove EXIF data for privacy (location coordinates especially) using Sharp's withExif: false.
Master resize: Resize the longest edge to 1920px while preserving aspect ratio. This becomes the "full" version displayed in the gallery lightbox.
Thumbnail generation: 400px wide thumbnail at 70% JPEG quality for the grid view.
Format optimization: Convert to WebP for the thumbnail (40-50% size reduction vs JPEG at similar quality). Keep full version as JPEG for compatibility.
Upload to R2: Upload both versions with content-type headers. Use multipart upload for files > 5MB.
Database insert: Insert photo record with gallery_id, original_filename, full_url, thumbnail_url, dimensions, file_size, and created_at.
Publish event: Publish photo:processed to Redis with the photo payload. The whole pipeline takes 200-500ms per image depending on original size. The bottleneck is almost always the resize step — Sharp's libvips backend is fast, but a 12MP image still takes 150ms+ to resize on a single core.

Live Gallery Updates: The Real-Time Experience

The gallery frontend is a React app with an infinite scroll grid. When a client connects, it joins a Socket.io room named after the gallery ID. The initial load fetches existing photos via a paginated REST endpoint. After that, all updates come through the WebSocket.

When a photo:processed event arrives, the client prepends the new photo to the grid with a fade-in animation. The effect is magical at events — you upload a photo from your phone and watch it appear on the big screen gallery within seconds.

One thing we learned the hard way: don't send the full photo object through the WebSocket. Early on, we sent the base64 thumbnail data in the event payload. With 50 new photos arriving in a burst, that was 50 × ~60KB = 3MB of data hitting every connected client simultaneously. Now we send only the CDN URL and metadata — clients fetch the thumbnail image from the CDN, which handles concurrent requests far better than a WebSocket connection.

Real-time photo sharing on Picshots follows exactly this pattern — metadata over WebSocket, image bytes over CDN.

Handling Failure Gracefully

At 500+ concurrent uploads, things will fail. The question isn't how to prevent failure — it's how to handle it without degrading the experience.

Upload failures: Client-side retry with exponential backoff (1s, 2s, 4s, max 3 attempts). If all retries fail, show a retry button on the failed upload.
Worker crashes: Redis Streams consumer groups with pending entries lists (PEL) ensure unprocessed jobs are re-delivered to another worker. We set an acknowledgement timeout of 60 seconds — if a worker doesn't ACK a job in 60s, it's considered dead and the job is requeued.
Database failures: Workers retry DB inserts 3 times with 1s backoff. If all retries fail, the job is moved to a dead letter queue for manual inspection. The photo doesn't appear in the gallery, but the upload isn't lost.
WebSocket disconnections: Clients auto-reconnect with backoff. On reconnect, they fetch any photos they missed via a REST endpoint that accepts ?after_timestamp= as a query parameter.

Performance Numbers

Here's where we landed after all three iterations:

Upload throughput: 500 concurrent uploads accepted and enqueued in under 8 seconds.
Processing latency: P50 of 3.2 seconds from upload completion to photo appearing in the gallery. P95 of 12 seconds under full load.
WebSocket fan-out: 500 connected clients receive a gallery update in under 50ms (Redis adapter + Socket.io rooms).
Memory per worker: ~80MB (Sharp's libvips is memory-efficient for single-image processing).
Total infrastructure cost: ~$45/month for a setup that handles 500 concurrent uploads (3 gateway instances, 2-8 workers, Redis, Postgres, R2 storage).

What I'd Do Differently

If I were starting over, three things would change:

Use a managed queue from day one. We started with in-process queueing, then moved to Redis lists, then to Redis Streams. If we'd started with BullMQ or even SQS, we'd have saved two weeks of rework on retry logic and dead letter handling.
Stream uploads directly to object storage. We save the raw upload to disk, then the worker reads it from disk. If we'd streamed directly from the upload gateway to R2 (presigned URLs), we'd eliminate the disk I/O bottleneck entirely. This is on the roadmap.
Measure earlier. We didn't add proper monitoring (Prometheus + Grafana) until iteration 3. Having P50/P95 latency dashboards from the start would have caught the event-loop blocking problem in iteration 1 much faster.

FAQ

Why Redis Streams instead of RabbitMQ or Kafka?

Redis Streams gave us consumer groups, pending entry tracking, and dead letter handling with minimal infrastructure. We already needed Redis for Socket.io's adapter, so using it for the queue too meant one less system to operate. For 500 uploads/second, Redis is more than sufficient. Kafka would make sense at 50,000+/second.

How do you handle duplicate uploads?

We generate a hash of the file content (SHA-256) on the upload gateway before enqueuing. The worker checks this hash against PostgreSQL before processing. If a match exists, the worker skips processing and returns the existing photo URL. This handles accidental double-submits from flaky mobile connections.

What about image moderation?

We integrated AWS Rekognition's content moderation API as an optional pipeline step. When enabled for a gallery, each processed photo is scanned before publishing. Photos flagged with high confidence are held for manual review. This adds ~200ms per image but is worth it for public-facing galleries.

Can this architecture handle 5,000+ uploads?

The architecture scales horizontally — more gateway instances, more workers, bigger Redis instance. The real constraint at 5,000+ is the database write path. We'd likely need to batch insert photo records or move to a write-optimized store (like ClickHouse) for the metadata layer. The queue and processing layers would scale fine.

Wrapping Up

Building a real-time photo gallery that handles 500+ simultaneous uploads taught me more about system design than any tutorial ever could. The journey from a single Express server that died at 50 uploads to a horizontally-scaled architecture handling 500+ was three months of trial, error, and incremental improvement.

The principles that got us there are universal: separate the hot path from the slow path, use queues to absorb bursts, scale workers horizontally, keep WebSocket payloads tiny, and handle failure explicitly at every layer. If you're building something similar, I hope this saves you a few of the dead ends I hit.

The gallery engine I built is now powering live photo experiences on Picshots. If you want to see it in action or have questions about the architecture, reach out — I love talking about this stuff.

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

ArtiDigital — Tue, 11 Aug 2026 22:00:05 +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

LayerTechnologyWhy

CameragetUserMedia + ImageCapture APINative browser APIs, no plugins
QR Generationqrcode (npm)82M monthly downloads, battle-tested
FrontendVanilla JS (~12KB)Fast load on slow event WiFi
Real-timeServer-Sent EventsSimpler than WebSockets, auto-reconnect
StorageS3-compatible + WebP thumbsCheap, scalable, fast gallery loads
OfflineService Worker + IndexedDBWorks when venue WiFi doesn't
HostingNode.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're planning an event, see how the guest photo upload experience eliminates the friction of app downloads entirely.

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.

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

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

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 Flash Surprise

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

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;
}

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);
  });
}

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);
  });
});

Storage: Optimizing for the Event Use Case

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

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

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

2. The BarcodeDetector API Is Underrated

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

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 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.

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.