The sign-up screen is the most quietly dishonest component in modern software, because it presents itself as a service to you, a way to keep your stuff safe and synced and reachable, when its actual job is to anchor you to a row in somebody else’s database so that billing, retention metrics, and the occasional marketing email have somewhere to attach. We noticed this the way you notice most things, by building apps and realizing the account system was the single largest feature we were about to write that our users had never once asked for, so we stopped writing it, and across Roamarr, Foxden, SpiderTypes, Sinema, and Tailshell there is no account on our infrastructure anywhere, with the one honest wrinkle being the local users that live on your own server where an app genuinely needs them, and the part worth writing about is not the privacy posture but what happens to your data model when the users table stops being ours.
What the users table was secretly doing
An account system is never just a login form, and anyone who has built one knows the shape of the iceberg: the users table drags in email verification, password hashing, reset tokens with expiry semantics, session management, rate limiting against credential stuffing, a GDPR deletion path, and a quiet permanent obligation to protect the one table that cannot leak. Remove the account and every one of those subsystems leaves with it, which is the first way the data model changes, not by gaining a privacy feature but by deleting a liability column from every design conversation you will ever have.
The second change is subtler and more useful, because without an account there is no global identity to key your data against, so every record in the app has to be owned by something physical instead: the device, the browser profile, the instance, the passphrase holder. That sounds like a limitation and it behaves like a design discipline, since the question “which user owns this row” collapses into “this row lives here, on this machine, in this store,” and a surprising amount of application complexity, the multi-tenancy checks and the per-user scoping and the accidental cross-user leaks waiting to happen, turns out to have been complexity you bought when you bought the users table.
The spectrum, because “no account” is not one thing
The honest version of this pattern is a spectrum rather than a slogan, and our own apps sit at four different points along it, which is worth walking through because the right point depends on what the app actually does.
SpiderTypes sits at the far end, the typing game where there is no identity at all: progress lives in localStorage, there is no backend to send it to, and the data model has no concept of a person, only of a browser that has played some levels, which is the correct model for a kids’ game because the less an app knows about a child the better, and the easiest COPPA-shaped problem to solve is the one where the data never leaves the device in the first place.
Sinema, the Android TV client, moves one step up with a local PIN, and the PIN is worth a sentence because it proves the pattern is about accounts, not about the absence of secrets: the PIN exists to keep the kids out of the grown-up library, it never leaves the device, it identifies nothing and no one, and it is a lock on a door rather than an identity in a database, which is all a lean-back media client ever needed.
Roamarr and Tailshell sit further along, where some form of authentication is genuinely required because the app holds things worth guarding, and the shape both of them chose is authentication that never becomes our identity system: Roamarr’s owner unlocks the instance with a passphrase that derives the encryption key, Tailshell keeps a real users list with JWT sessions and TOTP for admins, and the distinction that matters is where the table lives and who it answers to, since Tailshell’s users exist on your server, created by you, holding nothing we can see, while the vendor-hosted equivalent would anchor those same principals to infrastructure you do not control and terms you did not negotiate. Roamarr adds the piece that replaces the usual “invite your companion” flow, which is the scoped, revocable share link that exposes one trip and nothing else, and that design only exists because there is no account to invite people into; the absence of the feature forced the better feature.
Foxden is the interesting edge case, because it can sync and it does so by borrowing an account you already own rather than minting a new one: workspace data lives in Firefox’s own storage, and if you sign into Firefox Sync it travels under your Mozilla account on Mozilla’s infrastructure, which is a distinction we keep insisting on because it is real, user-owned sync under an identity the user chose for their own reasons, not a vendor account we created to hold their tabs hostage.
What you give up, said out loud
The pattern costs real things and pretending otherwise is how design posts turn into brochures, so here is the bill. You give up cross-device sync as a free consequence of architecture, because sync without a server in the middle is a hard problem, and the honest answers are the ones we shipped: Foxden defers to Firefox Sync, SpiderTypes accepts that progress lives on one device, and Roamarr’s answer is that the instance is the device, reachable from anywhere you choose to expose it. You give up password reset, entirely, and that one deserves a shudder, because a forgotten Roamarr passphrase means the encrypted fields stay encrypted forever, which is the guarantee working exactly as designed and exactly no comfort to the person standing in front of a locked backup, so the recovery story is a password manager and the responsibility moves to the person who owns the data, where it arguably belonged all along.
You also give up the support shortcut of “just log into their account and look,” and you give up the growth-hacker’s funnel, and we have written before about what flying blind costs, so the short version here is that the support conversation starts with “what do you see” like it is 2004, because it is, and the product gets better through the loud feedback channels or not at all.
The old default, back by choice
None of this is a new idea wearing a privacy costume, because the software that raised a generation of us, the shareware on magazine discs and the VB utilities passed around on floppies, had no account system for the simple reason that there was no one to have an account with, and the login wall only became a default when always-on connections made it free to build one, which means the account was never a user need at all, it was an ambient capability that hardened into a requirement without anyone deciding it should. The modern equivalent of that old default is not nostalgia for a simpler era, it is a sizing decision you make on purpose: keep the data where the user is, gate it with secrets that identify nothing, borrow the user’s own sync when sync is genuinely needed, and let the users table stay unwritten, because the apps that never learned your email address are the ones that can never lose it.