New App? Separate Users From Accounts (from DAY ONE)

When architecting a new web app, I try to stick to our V1 scope and avoid overbuilding things before we need them.

Examples:

- Building features "just in case" users ask for them later.
- Over-engineering features for scalability that won't be a concern for years.
- Laying groundwork for features we might build later.

...With one exception:

Separating Users from Accounts.

If you ever need to allow users to belong to organizations, and/or organizations having many users who use a single account in your web app, then you'll need to have the Users and Accounts databases separated, along with the ability to associate users with Accounts.

Your V1 scope might not call for this! So it's easy enough to only spin up a Users table, in the name of "stick to the scope!".

But later on, if you ever need to build account settings, multiple users (invites), or multi-account switching, this will be a very complicated (read: expensive and time consuming!) refactoring.

It's not much extra work to simply create both a Users and Accounts table from day one, along with a simple association. You can even wait on building the interfaces for user invites and account switching.

Some best practices have exceptions :)