We almost built Poolr as an app. Then we talked to real people.

The moment we realised friction kills good ideas

In the early days of building Poolr, we'd sketched out the usual flow. Download the app. Sign up. Log in. Invite guests. Hope they actually go through with it. It's the path every app takes, and there's a reason: control. You own the relationship. You can send notifications. You have a user base.

But we kept hearing the same complaint from our beta testers, who were mostly people planning small weddings and birthday parties. They'd send out links to fifty guests. Maybe thirty would download the app. Of those thirty, half would forget their password. By the time someone actually uploaded their first photo, the moment had passed. The wedding reception was over. The party was done.

One tester, a mother of the groom, wrote: "I just want to upload the photos from my phone camera without remembering another password." That's not a nice-to-have. That's the core problem we were meant to solve.

QR codes are old. But they solve a new problem.

We designed Poolr around a single assumption: friction is the enemy of memory collection. The moment someone has to think about signing up, they're gone. The moment they need to remember a password, you've lost them.

So we went the other way. Host opens Poolr, sets up an event in about two minutes, generates a QR code. Guest arrives at the party, sees a printed sign with that QR code. One scan. They're in a browser, on their phone, ready to upload. No account. No download. No password. The entire friction surface collapses into a single decision: upload or don't.

It meant we had to rethink everything behind the scenes. No accounts meant we needed a different way to verify guests. No persistent login meant we couldn't rely on traditional sessions. We had to make the upload experience so smooth that the lack of an app never felt like a limitation. And we had to design moderation differently, because we couldn't rely on user reputation or historical behaviour to flag dodgy uploads.

But the payoff was immediate. In testing, guest upload rates jumped from 30 percent to nearly 75 percent. People weren't abandoning the flow anymore.

Full resolution. Full control. No compromise.

We could have been clever about this. Compressed JPEGs. Thumbnails. Maybe some device-storage limitations to push people toward the app version. Freemium tactics are everywhere.

Instead, we decided: every photo that comes through the browser upload gets saved at full resolution. Whatever you shot on your camera or phone, that's what the host gets. No compression. No watermarks. No artificial scarcity to drive upgrades.

Why? Because when you're collecting memories from everyone at an event, you want the best version of those photos. The bride who receives three hundred full-resolution images from her guests can actually use them. She can print them. She can share them. She can decide what matters. And if she wants to go further, she can order a printed photobook straight from the gallery, or download everything as a ZIP and hand it to her wedding photographer.

The no-account thing enabled this. Without accounts, we're not storing photos indefinitely on our servers. We're not building an archive of your entire photo library. We're collecting event photos, keeping them together, and then either letting you download them, print them, or store them for a defined period. It's honest about what we are: a collection tool, not a cloud storage service.

What we gave up. And what we gained.

Building without an app meant losing some things we could have had. No persistent notifications. No ability to remind guests mid-event to upload. No recommendation engine to show guests photos their friends had taken. No algorithmic features that depend on historical user data.

We gained simplicity instead. Gained speed. Gained the ability to tell a wedding organiser, "I don't need to worry about technical problems." Because when the upload is just a web browser and a QR code, there's very little that can go wrong.

We also gained something less tangible: permission to move fast. Every feature we add now, we add it to the web interface. That single, simple experience. We're not deciding between the app version, the web version, and the version for people who didn't download yet. There's no fragmentation. There's just the fastest possible way to get a photo from your phone into a shared album with everyone else at your event.

For repeat hosts, we offer the Host+ subscription. For wedding planners and venues who manage multiple events, we built Pro Organiser and Teams. Those features live in a more persistent interface because those users are coming back, again and again, with different events. But the core upload experience, for every single guest at every single event, stays the same: scan, upload, done.

The things we still had to figure out

Removing the app didn't remove the complexity. It moved it. We still needed moderation, because without the app as a gatekeeper, we were more exposed to spam or misuse. We built a live moderation queue so hosts can review photos in real time, because trust matters when you're collecting from strangers.

We still needed to handle edge cases. Guests with slow connections. People uploading video alongside photos. Someone trying to upload 150 photos at once. Someone coming back to the same event link weeks later. All of that required thinking more carefully about the backend, not less.

And we had to accept that no-account meant no recovery mechanism if someone refreshed the page mid-upload or lost their connection. In practice, web browsers handle that gracefully now, but we spent months on that specific edge case because we couldn't rely on a user account to recover interrupted uploads.

Was it worth the extra engineering? Every single metric says yes. But it's also why we built it this way intentionally, not accidentally. We knew what we were choosing.