Why Authentication Is Your First Product Decision

The screen is trivial. The decisions behind it are not:

• What is the unit of identity? A person, or a person within an organisation? Retrofitting the second onto the first touches every query you have written.
• Can one human have multiple roles? In a marketplace, is a technician who also books jobs one account or two? XPERTS had to answer this before any matching logic could be written.
• Can an entity exist before its owner? Invitations, admin-created records, and imported data all require this, and it is painful to add later.
• What is the permission unit? Role, resource ownership, or both? Choosing "just roles" early is the most common source of a later rewrite.
• What is recoverable? If someone loses access, what proves they are them? For products holding sensitive data this is a policy question, not a technical one.

None of these are answered by picking an auth provider, which is why "we'll just use a library" does not resolve them.

1. Assuming one user, one account, one context

Almost every B2B product eventually needs organisations. If your user table is the centre of your data model and everything hangs off user_id, adding a tenant boundary later means touching every table, every query, and every permission check — usually while live.

Adding an organisation concept on day one, even when every organisation has exactly one member, costs very little and removes an entire category of future migration.

2. Roles as a single column

role: "admin" | "user" works until the first person needs to be an admin of one thing and a viewer of another. Model permissions as a relationship between a person and a resource from the start, even if you only have two roles.

3. Coupling identity to the login method

If your user record is the email/password record, adding social login or SSO later means merging accounts — one of the genuinely unpleasant migrations, because users have already created duplicates. Keep the identity and its authentication methods as separate concepts.

For some products, proving who someone is is the value. DualMatch is a clear case: a selective matching platform is only meaningful if participation is verified, so verification infrastructure had to be part of the foundation rather than a later trust-and-safety addition.

The design tension is real. Every verification step reduces fraud and reduces signups. The way through is to be explicit about which actions require which level of assurance, rather than applying one bar to everyone:

• Browsing may need no account at all.
• Creating content may need a verified email.
• Transacting or contacting another user may need identity verification.

Staging it this way lets people experience value before you ask them for effort, which is usually the difference between a funnel that converts and one that does not.

The technical flow ends when a session exists. The product flow does not.

What happens immediately after first sign-in determines whether the account becomes a user. The questions worth deciding deliberately:

• What is the minimum you need before the product is useful? Everything else can be asked later, in context.
• What does an empty account look like? The empty state is the first real screen most users see, and it is routinely designed last.
• Can they try before committing? For Dental Anxiety Adieu the onboarding had to introduce the product gradually and gather assessment information without feeling clinical — the sequence mattered as much as the questions.

Treating onboarding as part of the same milestone as authentication keeps these decisions together, where they belong.

Write down the answers to these before the first migration:

1. Is the account a person or a person-in-an-organisation?
2. Can one person hold more than one role, and can roles differ per resource?
3. Can a record exist before its owner has signed up?
4. Which actions require which level of verification?
5. How does someone recover access, and what proves identity?
6. What happens to their data if they leave, and who can delete it?
7. Will you need SSO for business customers within two years?

Half an hour on these, before any code, routinely saves a migration that would take weeks.

Build the identity model for the product you expect in eighteen months, and the sign-in screen for the product you have this month.

The data model is expensive to change and invisible to users. The interface is cheap to change and is all they see. Investing on the wrong side of that line is the mistake, and it almost always goes the same direction: a beautiful sign-in flow sitting on a model that cannot express what the business needs.