Listful
← Back to blog

How We Built No-Account Sharing (And Why Everyone Else Didn't)

Every other shopping list app I tried had the same pattern: I'd install it, create an account, then try to share a list with my partner. She'd tap the link, land on a signup screen, sigh, and put the phone down. The list died before it started.

So when we built Listful, we made a deliberate bet: the second person never signs up. You send them a link, they tap it, they're on the list. No email, no password, no account. This post is how we actually pulled that off, what it cost us, and the moments it almost fell apart.

Why Every App Wants Accounts

Before the how, the why — because the answer to "why doesn't anyone do this already" is usually "because it's harder than it looks."

Accounts solve a half-dozen problems for you as an engineer:

  • Identity. You know who did what. Every piece of data is owned by a user ID, easy to track, easy to sync, easy to authorize.
  • Cross-device continuity. Install the app on a new phone, log in, your stuff is there.
  • Monetization later. Premium features, targeted emails, win-back campaigns all assume a durable user record.
  • Abuse control. Rate limits per user, account bans, suspicious-activity detection — all of it keys on "who is this."
  • Simpler data model. "Belongs to user X" is the cleanest ownership semantic in any database schema class ever taught.

Removing accounts gives up most of that. If you want to share state between two devices with no shared login, you have to invent a different identity primitive. That's what we did.

The Bet in One Sentence

A list itself is the unit of identity, not a user.

That one rethink made the rest of the architecture fall out of it. The way we talk about it internally: a list is a small public dossier with a secret URL. Anyone with the URL is a co-owner. No user rows, no login table, no password resets.

It sounds simple. The implementation has a few sharp edges.

How a Share Actually Works

Here's the abbreviated flow when you tap "Share" in Listful:

  1. The app mints a short share token — a random, URL-safe string of ~10 characters, cryptographically generated. Collision probability is astronomically low in our key space, and we check uniqueness before finalizing.
  2. The token becomes part of a short URL: listful.app/s/abc123xyz.
  3. That URL is sent via the share sheet — Messages, WhatsApp, whatever.
  4. When the recipient taps the link, the app (if installed) or web (if not) opens the list in read-write mode. They're now a participant.
  5. Under the hood, their device generates a local device key — no PII, no email, just a key — and that key gets associated with the list so their edits are attributable (to "Device 2") without ever knowing who they are.

The server stores: the list contents, the share tokens, and device-key associations per list. That's it. No users table. No auth table. No session table.

The Unglamorous Parts

The five paragraphs above make it sound clean. In practice, three things were harder than we expected.

1. What happens when you lose your phone

With accounts, "lost phone" is a password reset email away. Without accounts, the device key is your proof of ownership. Lose the phone, and technically you've lost access to the list — unless someone else still on the list can re-share it to your new device.

We made that the answer. Any existing device on a list can re-share it. If you're the only device on a list and you lose the phone, the list is effectively orphaned. That's a real tradeoff we chose: no password means no password recovery.

In practice, approximately nobody has hit this problem. Most lists are shared with at least one other person precisely because sharing is the whole point. The solo-user-loses-phone case is real but rare, and we mitigate it with optional iCloud backup of the list state — entirely opt-in, handled by iOS without any account on our side.

2. Abuse and rate limiting

Account-based apps rate-limit "per user." We can't do that. What we limit:

  • Per device key for writes. Each install gets a device key, and that key has a write budget. Spam from a single install gets throttled quickly.
  • Per share token for reads. Each share URL has a ceiling on how often it can be fetched — well above any legitimate use case, low enough to stop scraping.
  • Per IP as a fallback for misbehavior that slips between the other two. Not perfect, but effective for 99% of nuisance traffic.

The honest truth: the abuse surface of a grocery list app is small. Nobody is trying to SQL-inject "oat milk." The main attack category we worry about is enumeration — someone guessing share tokens to find other people's lists. Our 10-character token space makes that computationally absurd, and we add exponential backoff on invalid-token requests. It's fine.

3. The "who made this change" question

With accounts, every edit is attributable to a name. With devices, edits are attributable to "Device 2." That's fine for a household where "Device 2" is obviously your partner — but it breaks down when six people are on a list. "Device 4 added almond milk" doesn't tell you if that was your mum or your housemate.

Our current answer: a device can set a display name ("Kate") stored locally and synced through the list. That name is visible to other participants without ever being tied to a verified identity. It's Trust-On-First-Use: you trust that "Kate" is actually Kate because Kate told you she'd set that name on her phone. In a household-sharing context — which is 95% of our usage — that's more than enough.

For larger-group sharing (a shared office kitchen, say), this is thinner. We may revisit it. But we explicitly don't want to solve "prove this is really Kate" because the moment we do, we're back to accounts.

Tradeoffs We Accepted, and Which Ones Paid Off

Accepted: no email marketing, no user lifecycle analytics, no "welcome back" automation, no sales funnel. In exchange, we got: no sign-up wall, no GDPR user-account compliance surface, no password reset flow, no "forgot my email address" support tickets, and meaningfully lower operational complexity.

Accepted: no cross-device continuity without iCloud. In exchange: no identity-theft surface area, no "we got breached" press release risk, no password manager integrations to worry about.

Accepted: no personalization that requires user history. In exchange: the app runs cold-start fast, with no login overhead on launch.

The one we'd do again ten times out of ten: zero friction for the recipient. The second person's experience is the entire game. They tap a link and the list is there. Ninety percent of our "we love Listful" messages mention that moment as the thing that sold them.

What We Wouldn't Recommend Doing Blindly

Before anyone reads this and goes "I'll do the same for my app" — account-less sharing makes sense in a specific slice of the product space. Use it when:

  • The data has low individual sensitivity but high immediacy (shopping lists, packing lists, trip plans).
  • The sharing dynamic is small-group and trusted (households, couples, travel buddies).
  • You genuinely don't need user analytics, cross-device continuity as a default, or per-user monetization.

Don't use it when:

  • The data is sensitive (health, finance, private journaling).
  • You need strong identity guarantees (collaboration with non-trusted parties, enterprise workflows).
  • Your business model depends on individual user tracking or lifetime-value analysis.

For Listful, the fit was perfect. For your banking app: please, God, no.

The Part That Surprised Us

We thought we were making an engineering decision. We didn't realize how much of a product decision it was.

Removing the account wall changed who tried the app. Partners of existing users tried it because there was nothing to commit to. In-laws tried it. Friends-of-friends tried it. Our organic growth ended up being dominated not by new primary users, but by second users who'd been dragged onto a list by someone else and decided it was worth keeping.

Accounts, it turns out, aren't just a data model. They're a commitment asked of the user. Sometimes that commitment is worth asking for. For a shopping list between two flatmates, it absolutely is not.

If you're building something in the low-friction, low-sensitivity, high-collaboration corner of the product space, seriously consider whether you need accounts at all. We've been quietly running without them for years, and the thing we notice most is how rarely we miss having them.

Listful is a free iPhone and Apple Watch app that does shared shopping lists without accounts. Download it on the App Store and send the link to whoever you shop with. No signup on either end — that's the whole system.