🎭 Designing a User Model for Multiple Roles (Without Losing Your Mind)

You know that moment when your app suddenly needs more kinds of users?

You start with a simple User model — just name, email, password.
Life is peaceful. Everything makes sense.

Then your PM drops the bomb:

“We need admins, vendors, and customers.
And some users can be all three.”

Now you’re staring at your schema thinking,

“Maybe it’s time to switch careers.” 😅

Don’t panic — we’ve all been there.

In this post, we’ll design a clean, scalable, multi-role user system — the kind that won’t collapse the moment your startup adds a new user type.

We’ll explore:

• The bad ideas (you’ve probably written before)
• The better ideas
• And finally, the best structure — one user table + separate profile tables.

🧱 1. The One-Table Disaster

Most apps start like this:

User { id: string name: string email: string password: string role: 'admin' | 'vendor' | 'customer' storeName?: string walletBalance?: number } 

It looks fine — until reality hits.

• Customers don’t have storeName
• Vendors don’t have walletBalance
• Admins don’t need half the columns

Now your table looks like a junk drawer full of nullable fields.
Welcome to the God Table Anti-Pattern — one table trying to be everything, and doing nothing well.

🪓 2. The “Split Everything” Overcorrection

Then comes the overcorrection phase:

Admin { id, name, email, password, permissions } Vendor { id, name, email, password, storeName } Customer { id, name, email, password, walletBalance } 

Looks cleaner, right?
Until you realize you just broke your system in three places.

Now you have:

• 3 login routes
• 3 sets of authentication logic
• 3 password reset flows

And worst of all:
A user can’t be both a vendor and a customer without two separate accounts. 🤦‍♂️

That’s not role-based — that’s multiple-account chaos.

💡 3. The Smarter Way — “User + Profiles”

Here’s the scalable approach:

• Keep shared user data (like email, password, name) in a single User table.
• Create separate tables for each role’s profile (AdminProfile, VendorProfile, CustomerProfile).
• Let one user have multiple profiles linked to them.

Think of it like this:

The User is the person.
The Profiles are the hats they wear.

So, Sarah can:

• Log in once ✅
• Buy products as a customer 🛒
• Sell items as a vendor 🏪
• Manage users as an admin ⚙️

All through one account.

🧭 4. Visualizing It

 +------------------+ | User | |------------------| | id | | name | | email | | passwordHash | +--------+---------+ | +--------+---------+ | | +----------------+ +----------------+ | VendorProfile | | CustomerProfile| |----------------| |----------------| | id | | id | | userId (FK) | | userId (FK) | | storeName | | walletBalance | | businessType | | preferences | +----------------+ +----------------+ +----------------+ | AdminProfile | |----------------| | id | | userId (FK) | | permissions[] | | accessLevel | +----------------+ 

⚙️ 5. Schema Example (Prisma-style)

Here’s what that looks like in a clean ORM setup:

model User { id String @id @default(uuid()) name String email String @unique password String createdAt DateTime @default(now()) adminProfile AdminProfile? vendorProfile VendorProfile? customerProfile CustomerProfile? } model AdminProfile { id String @id @default(uuid()) userId String @unique user User @relation(fields: [userId], references: [id]) permissions String[] accessLevel String } model VendorProfile { id String @id @default(uuid()) userId String @unique user User @relation(fields: [userId], references: [id]) storeName String businessType String } model CustomerProfile { id String @id @default(uuid()) userId String @unique user User @relation(fields: [userId], references: [id]) walletBalance Float preferences String[] } 

It’s modular, readable, and future-proof.
Adding a new role later? Just create a new profile table. No migrations. No mess.

🧠 6. Real-World Example

Meet Sarah.
She signs up on your platform.

1. ✅ Starts as a Customer → creates a CustomerProfile
2. 🏪 Opens her store → creates a VendorProfile
3. ⚙️ Joins your team → adds an AdminProfile

Still one login, one token, one user record.
She just switches context — your backend handles the rest.

🔍 7. Why This Wins

✅ Separation of concerns — shared auth, separate business logic.
✅ Extensible — new roles = new tables, not new headaches.
✅ Clean authorization — role checks happen on profile level.
✅ Reusable auth — login once, access multiple contexts.
✅ No null fields — because every role owns its own schema.

🚀 8. Wrapping Up

Good system design is like clean UI — invisible when done right.

This User + Separate Profile Tables approach gives you:

• Flexibility
• Scalability
• And peace of mind 😌

As your app grows, you’ll thank yourself for choosing this pattern.

Because the next time someone says:

“We’re adding moderators now…”

You’ll just smile and create a ModeratorProfile table. 😎

💬 Coming Next

In the next article in this series:

Role-Based Access Control (RBAC) with User Profiles
— How to attach permissions dynamically and secure routes in your backend elegantly.