We ditched user accounts. Here's why.
Three weeks into Feedr's beta, a church pastor emailed to say the sign-up flow was killing her. Not the concept. The friction. She'd tested it with a hundred people in her congregation, and a third of them bounced at the login screen. That email changed how we thought about identity.
The problem we thought we had
Most platforms start with accounts as the foundation. It's standard practice. You sign up, you get a profile, you have history, you have ownership. Makes sense in theory. But we kept hitting the same wall in user testing: people who wanted to run a live Q&A or gather audience reactions from a conference room didn't want to deal with account creation. And their audiences definitely didn't.
We realised we were solving for persistence when what creators actually needed was speed. A speaker who has six minutes between sessions doesn't have the bandwidth to explain why attendees need to create yet another login. Neither do the attendees, frankly. The moment someone asks 'Do I need to download an app?' or 'Do I have to create an account?', you've already lost them.
So we asked a harder question: what if we didn't require accounts at all?
Device UUID changed the calculus entirely
A device UUID is a unique identifier tied to the hardware itself, not to a person. It sounds technical, but the user experience is the opposite. An audience member scans a QR code in their browser. That's it. Their device is known to the session. They start commenting, upvoting, reacting. No signup. No password. No email confirmation screen.
For the host, it's even simpler. You run Feedr on your iOS or Android phone. That device becomes your identity for that session. Your session report, your comment moderation queue, your analytics dashboard - all tied to that device. When you run your next session, it's the same device, so you've got continuity. You don't need to remember a password or two-factor code. You don't need an account recovery flow.
The technical trade-off was real. We lost a few things. Users can't log in from multiple devices. They can't access their session history from a web dashboard. But what we gained was worth infinitely more: zero friction for the 95% use case.
What we learned from the smaller numbers
When we launched the Free tier - 3 sessions per month, up to 100 audience members - we expected it to feel limiting to creators. It does, but not the way we thought. Nobody complained about the session count. They cared about reaching their people without a complicated setup. A lecturer running a small workshop doesn't need unlimited sessions. They need one session to work brilliantly.
The device-based model scaled that perfectly. Creators on the Free tier could invite their audience, run their session, see their comments, pin the good ones, and move on. No account overhead. No permission scoping. No 'forgot your password' emails tangling up the experience.
When they grow into the Creator tier - unlimited sessions, 500 audience cap, comment moderation tools, emoji reactions, guest moderator invite links - the same device-first model keeps working. They're not managing a new account. They're just expanding what their device can do.
The trade-offs we live with
Being honest, this choice carved out some limitations. If a speaker wants to run Feedr from their laptop one week and their phone the next, they're technically two different devices. We don't have a web-based host dashboard where you can see all your sessions from one login. You can't share session moderation between two people unless they pass the phone back and forth, which is silly.
For a certain slice of creators - think conference organisers managing dozens of speakers, or enterprises running training programmes across multiple teams - those gaps would push them elsewhere. And that's fine. We're not trying to be everything. We're trying to be the fastest, least-friction way for a human on stage to understand what their audience is thinking, right now.
The people we've built Feedr for don't need multi-device sync or enterprise SSO. They need to scan a QR code and know it works. That's the trade we made, and we stand by it.
Identity without the apparatus
The deeper thing we learned is that identity and persistence are not the same thing. You can have a real, verifiable identity without needing to persist personal data across sessions. Your device is you, for the duration of that session. That's enough.
It also meant we could keep the privacy surface clean. We're not storing email addresses. We're not managing password reset workflows. We're not building another data silo that might get breached. Your session data lives on your device until you choose to look at your analytics (Pro tier) or review your comment moderation queue (Creator tier and up). Then it's available, but it's never the prerequisite.
That simplicity is what made the pastor's congregation come back. No account. No friction. Just a QR code and a live feed of what people were thinking in real-time.
If you've ever felt the sting of creating yet another account just to participate in something once, you know why this matters. The question isn't whether you need user accounts. It's whether the problem you're solving actually requires them.
Ready to try Feedr by MRVL?
One tap to download. No sign-up wall.