It all started with a shopping list. My partner sent me a photo of it – and shortly afterwards another message, because she had thought of something else. You simply can't add to a photo after the fact. But she didn't want an app that made her sign up somewhere first, either. That's how the idea for Shared Lists was born.
Shared Lists is my own web app for shared lists – whether for shopping, to-dos or wish lists. More than 36,000 lists have been created with it so far, and not a single user account was needed for any of them. In this article I'd like to show you the decisions behind the app and what I learned along the way.
Decision 1: No account, no sign-up
A list in Shared Lists is created instantly and shared with a simple link. Anyone who has the link can join in – no email address, no password, no confirmation email.
This decision has several advantages:
- Getting started is as easy as it gets. Only a few seconds pass between "I need a list" and "the list is shared".
- Hardly any personal data is stored. What isn't collected doesn't have to be protected, managed or deleted.
- The people joining in don't have to set anything up. With shared lists this is crucial: it's not enough for one person to like the app – everyone involved has to be able to open it without any hurdle.
At first, I simply didn't want anyone to have to register and log in. Then simplicity came into play, in the code as well: what doesn't exist doesn't have to be built and maintained. And to be honest, I was also drawn to the challenge of building as much as possible without any personal data at all. I wanted to show how much is possible without the app – or me as its operator – knowing who uses it.
Of course, doing without accounts has a downside: without a login, the app initially only knows which device a list was created on. If you switch smartphones or want to see your lists on your laptop as well, you need a different solution.
Decision 2: Passkeys instead of passwords
That solution is passkeys. They only came later, though: when I built Shared Lists, passkeys were hardly widespread. Today they let you restore your own lists on any device – without an account, without an email address and without a password. On a new device you simply confirm the restore with your fingerprint, face recognition or the device PIN.
According to the Shared Lists passkey page, the only thing stored is a public key linked to the anonymous identifier of your lists – no name and no email address. Because passkeys sync through existing services such as Apple's iCloud Keychain or Google Password Manager, they are usually available on your own devices automatically.
For me, passkeys were a blessing. Until then, syncing your own lists between different devices had really been the biggest problem. On top of that came a quirk of the iPhone and iPad: under certain circumstances, Safari clears data that websites store locally in the browser on its own – and with it, access to your own lists could be lost. Passkeys solve both. They are the bridge between two goals that would otherwise contradict each other: as little data as possible, but still no data loss.
Decision 3: Changes in real time
A shared list is only really useful if everyone sees the same state. If someone at home remembers that the milk has run out, the new item should show up on the smartphone in the supermarket immediately – without anyone there having to reload the page. After all, that was exactly the problem with the photo of the shopping list.
Technically, I use WebSockets for this. They keep a connection open between the browser and the server, over which changes are sent to everyone involved right away. The app itself is built with Laravel and Vue and set up as a progressive web app (PWA). That means you can install it on your smartphone straight from the browser, and it then feels like an app from the store.
Decision 4: One-time payment instead of a subscription
Creating and sharing lists in Shared Lists is free. If you want more, you can upgrade a list to Pro. Among other things, that includes:
- adding items from a photo
- push notifications
- simple calculations
- setting permissions for participants
Pro is paid for once, not as a subscription. I handle the payments through the payment provider Mollie.
To be honest, this was a technical decision at first: without a user account, there is nobody you could bill every month – you pay for a list, not for a person. So it simply wasn't possible any other way. But then I also really liked the idea of not creating any dependency. You pay once, you know what you get, and you never have to remember to cancel.
Decision 5: Six languages from the start
Shared Lists is available in German, English, Spanish, French, Italian and Portuguese. Because the app works without an account and spreads via links, it quickly reaches people in other countries. A shared list should be understandable for everyone, no matter which language the person who created it speaks.
By the way, I can't say exactly where the users come from – with an app whose most important feature is anonymity, that's in the nature of things. All I know is that people from South America and Australia have already paid for the Pro features. Which list it was for, I can't even trace in the database.
What I learned from it
Looking back, there are three points above all that I also bring to my clients' projects:
- Every hurdle costs users. A registration form often isn't necessary. It's always worth asking: do we really need this data?
- Data minimisation and convenience don't rule each other out. Modern methods such as passkeys let you combine both goals.
- The payment model is part of the product. Whether it's a subscription or a one-time payment helps decide how an application feels to the people who use it.
What surprised me most is how far the app has spread without any marketing at all. There was once a Facebook account for Shared Lists, but never any real advertising. Even so, payments come in from many regions of the world. A list you share is always an invitation to the next person, too.
Conclusion
Shared Lists shows that a useful web app doesn't necessarily need an account, a password or a subscription. Often the simplest solution is also the one people like using most.
If you have an idea for a web application yourself or would like to simplify an existing process, take a look at my services and other references. Or write to me – I look forward to your questions.
Yours, Michael Becker