Local-First, No Login: What You Get and What You Give Up

CareReady has no sign-up screen. Open the URL and you’re using it. Every checklist, every box assignment, every per-destination memo, the outing dates, the little diary — all of it lives in the browser (IndexedDB), on the device, and nowhere else. There is no account, and there is no cloud copy.

That’s a deliberate stance, and it’s worth being honest about both sides of it.

What “no login” actually means here

The data model is: one device + one browser = one dataset. There’s no server row keyed by a user. So:

• Two people opening the same URL on their own phones get two completely independent, private datasets. Neither sees the other’s memos. Nothing is shared by virtue of sharing a link.
• Clearing site data, switching phones, or using a different browser starts fresh — because the identity is the local store.

For a belongings checklist that one family fills in for one relative’s stay, that mapping is almost exactly right. The people who use CareReady are often 50–70, packing a bag one-handed while a real person waits. A sign-up wall in front of a checklist is friction with no payoff for them, and care logistics are private enough that “we never send it anywhere” is a feature, not a limitation.

What still works without an account (almost everything)

The whole app runs locally. The server exists only for a few narrow, opt-in things, and none of them need a login:

• Feedback → an anonymous POST.
• Facility templates → redeem a short code to fetch a belongings list; nothing about you goes up.
• OCR → send a photo of a paper list, get items back.
• Reminders (Web Push) → the interesting one. The server stores only an anonymous push subscription and sends an empty “check now” ping on a schedule. The Service Worker then reads the local outing dates and decides whether to show a notification. So even reminders keep your schedule on the device — the server never learns when or where anyone is going.

You can build a genuinely useful, notification-capable app where the account is simply absent, not “optional.”

What you give up (say it out loud)

Local-first isn’t free, and pretending otherwise burns users later:

• No sync. Your phone and your tablet are separate universes. Write a memo on one, it isn’t on the other.
• No backup. Lose or wipe the device and the data is gone. There’s no “log back in and it’s all there.”
• Shared devices leak within themselves. One family tablet, one browser profile — everyone using it shares the same local data.

These are real, and for some products they’d be disqualifying. For a per-trip packing aid they’re mostly acceptable — but they’re the reason I keep the tradeoff visible rather than quietly hoping no one notices.

The upgrade path (don’t pre-build it)

The nice thing about starting local-first is that accounts remain a later option, not a foundation you have to lay now. When a real need shows up — “I want the same list on my tablet,” “I want a backup,” “I want to hand the list to a helper” — you add optional sign-in and treat the cloud as a sync layer over the local source of truth, not a replacement for it. The offline-first behavior people already rely on stays intact; syncing just becomes an enhancement for those who ask.

Building it the other way — account-first, cloud-first — would have meant every one of those nervous first-time users hits a login before they can pack a single sock. We chose to let them pack first, and to add identity only when a feature genuinely needs one.

Takeaway: default to local. It removes friction and keeps private data private, and it works for more than you’d think — even push notifications. Add accounts when a feature (sync, backup, sharing) actually requires one, not as the price of admission.

This is part of building CareReady, a released web app at VEAI LAB. My broader technical-PM profile is at hire-veai.com.