Why Some Apps Should Not Have Accounts

It is easy to treat authentication as the beginning of a serious app: add profiles, a database, analytics, and cloud sync before the first product loop is clear. Those tools can be exactly right. They can also add friction and operational obligations without improving the thing a person came to do.

PassportPlate is a useful counterexample because its core experience was intentionally kept account-free, cloud-free, and analytics-free. A person can install it, discover recipes, save local history, and use it offline without first establishing an identity. That is not an absence of architecture. It is an architectural choice matched to the product.

Start with identity, not a provider

The decision framework is simple, though the answer is not:

Does the core product require identity?
  No -> Can the state live safely on-device?
          Yes -> Would cloud sync materially improve the product?
                   Yes -> Is that benefit worth its operational and privacy cost?

An account is justified when the product needs multi-device sync, shared state, collaboration, cross-platform access, durable cloud backups, server-authoritative functionality, or paid server-side services. A social product may need identity to establish who can see or change something. A service that performs costly work on a server needs an accountable caller and a way to enforce limits.

But a focused single-device tool does not automatically become better because it has a login screen. If the core data is safe and useful locally, local state can make the first use faster and keep the app valuable in a tunnel, on a plane, or during a service outage.

Every account creates obligations

An account has a lifecycle: creation, authentication, session refresh, recovery, support, deletion, and possibly linking across providers. Cloud sync needs conflict rules, migrations, retry handling, and an answer for partial failure. Analytics introduces disclosure and governance questions. A backend adds security surface, monitoring, cost, deployment, and a service that can fail independently of the app.

None of that makes those systems bad. It makes them product commitments. An app that collects identity must protect it and explain why it needs it. An app that creates accounts needs a deletion workflow; Apple explicitly requires an in-app path for apps that support account creation. A product that promises sync must decide which edit wins when two offline devices disagree.

The cost is also cognitive. Login changes first launch from “open and try” to “choose a provider, consent, handle a redirect, recover a password.” Some products earn that friction immediately. Others should let value come first, or never require it.

Local can be an honest product promise

Keeping data on-device narrows the system. There is no account deletion queue for data that never left the device, no authentication support path, and no server-side analytics pipeline to govern. It also sets boundaries: an uninstall may remove data; a new device may not see old saved items; collaboration is not available. These are not implementation footnotes. They must be communicated through the product's behavior and help content.

For PassportPlate, local content and history fit the promise. It does not claim shared cooking lists, cross-device recovery, or a personalized cloud service. Its account-free core also supports the privacy choice directly: the application does not need to know who is cooking in order to help with dinner inspiration.

Avoid infrastructure theater

A backend, microservice, AI feature, or complex sync layer can signal technical ambition, but sophistication is not the goal. The better question is what user problem it solves that simpler architecture cannot. More infrastructure creates more states to test and more situations where an ordinary feature cannot render because a remote dependency is unavailable.

That tradeoff can change. A future collaboration feature may justify accounts. A local product may later offer optional backup. The disciplined move is to introduce that infrastructure when the product requirement is concrete, then design its lifecycle fully—not to build it preemptively as decoration.

Optionality is not free either. “Add sync later” is a sensible roadmap item only if local identifiers, exports, and data ownership are designed so a later transition remains possible. It does not require shipping an unused backend today. It means avoiding choices that make future user data impossible to map or migrate without a plan.

The offline-first React Native guide explores the storage, migration, and sync implications in more detail. The broader lesson is the same one behind my approach to AI and architecture: tools should serve an explicit product boundary. Infrastructure should exist because the product requires it, not because it makes the architecture look sophisticated.