A shared account is one of those ideas that sounds purely convenient until it becomes architecture.
The visible promise is simple: sign in once and move between products without creating another password, verifying another email address, or rebuilding the same basic profile. The invisible possibility is more consequential. Once every product recognizes the same person, an organization can combine what that person searches, writes, reads, plays, buys, and discusses into a single behavioural record.
Convenience and consolidation arrive through the same door. They do not have to stay together.
The Busted Minds Account is built around a distinction that large platforms often blur: shared identity does not require shared activity. Knowing that the same person is permitted to enter BM Chess and BM AI is different from treating a chess loss and a private conversation as features in one profile.
Authentication is not observation
An account has several legitimate jobs. It can verify identity, recover access, maintain security settings, remember explicitly chosen preferences, and show which products are connected. None of those jobs automatically requires a central timeline of behaviour.
This sounds like a technical distinction, but it changes the relationship with the user. When identity and observation are fused, signing in becomes blanket consent to be understood across contexts. A question asked in Search can influence an assumption in AI. A late-night game can become evidence in an engagement model. A bookmark can enter an advertising category the person never knew existed.
Context matters because people are not single-purpose datasets. We explore ideas we do not endorse. We search for problems on behalf of friends. We play badly when tired. We draft private thoughts that should not harden into permanent identity. Systems that collapse these moments into one profile gain apparent completeness by deleting their meaning.
Separation is a way to preserve that meaning.
Data boundaries should match human boundaries
Organizations often structure data around what is operationally easy: one customer table, one analytics pipeline, one place where every event can be joined. Users structure life differently. A work conversation, a game, a health question, and a public comment may all happen on the same device while belonging to different parts of the self.
Good account architecture recognizes those boundaries even when the database could ignore them. Each product should collect what it needs for the service it provides. Cross-product access should be explicit. A useful shared feature should explain why information must travel rather than treating technical possibility as permission.
This principle also limits blast radius. Separation cannot eliminate security risk, but it can reduce the number of unrelated facts exposed when one system fails. Privacy and security meet here: both benefit when data is not copied, joined, or retained without a specific purpose.
The respectful default is not “collect now, govern later.” It is “keep separate until the user chooses a reason to connect.”
Permission must be understandable before it is granular
Privacy controls are often praised for being comprehensive. A screen with forty toggles may be comprehensive in the way a contract is comprehensive: every choice exists, but the cost of understanding it has been transferred to the person with the least context.
Clear permission starts with plain categories. Which product is asking? What information does it need? What new capability will the connection provide? Is access temporary or continuing? Can the person reverse the decision without losing unrelated parts of the account?
Granularity still matters. A user may want an AI coach to inspect selected chess games without granting access to their full history. They may want to save a Search result into a chosen conversation without allowing all queries to flow into AI. The unit of permission should follow the task whenever possible.
The interface should also reveal state. People should not have to remember a consent dialog from six months ago. A central account page ought to show connected products, current access, recent security events, and a direct path to disconnection.
Deletion is part of the design
Many systems treat deletion as a support process attached after the product is built. That produces predictable friction: unclear retention periods, data spread across backups and derived tables, and warnings that make leaving feel reckless.
Deletion works best when it is designed alongside creation. If a product cannot identify which data belongs to a user, which records must be retained for legal or security reasons, and which derived artifacts will survive, then its privacy promise is mostly rhetorical.
A shared account introduces an additional responsibility: deleting activity in one product should not accidentally destroy the person's identity everywhere, while deleting the identity should not leave unexplained product profiles behind. The choices must be distinct and their consequences legible.
This is not glamorous product work. It is exactly the kind of work that determines whether “user control” is real.
Portability makes choice credible
The freedom to leave is not meaningful when departure means abandoning years of personally valuable work. A product earns trust when it can imagine the user's future outside itself.
Portability can take different forms: an export a person can read, a standard another service can import, or a documented way to retrieve material without negotiating with support. The ideal format depends on the product. The principle does not. User-created value should not become a hostage simply because the service stored it.
This is especially important for a product collective that asks people to try alternatives to established products. That request would be hypocritical if our own growth depended on making the next alternative difficult to choose.
The convenience worth keeping
There is a version of privacy that responds to platform excess by making every service isolated, anonymous, and difficult to use. That is not our goal. People reasonably want one secure identity, reliable recovery, and a clear place to manage their relationship with an organization.
The task is to keep that convenience while refusing the assumption that a complete customer dossier is the natural price.
Our standard for the Busted Minds Account is therefore practical:
- One sign-in should reduce repeated security work.
- Each product should keep its activity separate by default.
- Permissions should describe a human benefit, not merely a data scope.
- Connections should be visible and reversible.
- Removing data or leaving a product should be a supported path, not an adversarial one.
Architecture cannot guarantee virtue. Policies change, teams make mistakes, and any system may fall short of its own principles. What architecture can do is make respectful behaviour easier and quiet overreach harder.
An account should recognize you when recognition is useful. It should not follow you simply because it can.
Loading the conversation…