Template EmpireA has_access boolean can unlock a paid feature. It cannot run a B2B SaaS platform.
Many SaaS starters begin with a simple model: one user, one account, one subscription, one set of records. That can be perfect for consumer tools, paid downloads, solo dashboards, and simple MVPs.
The problem starts when that model is sold as a foundation for team software.
If you need organisations, roles, invitations, shared billing, audit trails, custom domains, or per-tenant data isolation, you need more than user.hasAccess.
Single-user SaaS and B2B SaaS are different products
A single-user app usually asks:
- Who is the user?
- Have they paid?
- Which records do they own?
A B2B app asks:
- Which organisation is active?
- Is the user a member?
- What role do they have?
- Which resources belong to this organisation?
- Who pays for the organisation?
- Who can invite, export, delete, or administer?
- What should be logged?
Those questions change the database, routes, permissions, billing model, and UI.
The core objects in a team-based SaaS
A typical B2B model includes:
User: the human identity.OrganisationorWorkspace: the tenant boundary.Membership: the link between user and organisation.Role: the named permission set.Permission: the action allowed.Resource: the thing being accessed.Invitation: the pending membership flow.AuditLog: the record of sensitive activity.Subscription: the billing relationship.
The exact names do not matter. The separation does.
If a starter stores all ownership directly on userId, retrofitting organisations can be painful.
Membership is not the same as ownership
In a team product, a user can belong to multiple organisations. They may be an owner in one, an admin in another, and a viewer in a third.
That means the app needs an active organisation context.
Common questions:
- How does the user switch organisations?
- What happens if the active organisation is deleted?
- Can a user be removed while they are logged in?
- Can a user accept multiple invitations?
- Do URLs include organisation slugs or IDs?
- Are records fetched through the active organisation boundary?
A single userId check cannot answer these safely.
RBAC should be enforced on the server
Role-Based Access Control is often displayed in the UI but forgotten at the server boundary.
A real RBAC system should answer:
- Can this user view this resource?
- Can this user create this resource?
- Can this user update it?
- Can this user delete it?
- Can this user invite others?
- Can this user manage billing?
- Can this user export data?
- Can this user change roles?
These checks must happen where data is read or mutated. Hiding buttons is not enough.
Billing entitlements and roles are different
A subscription controls what the account has paid for. A role controls what a person can do.
For example:
- The organisation may be on the Pro plan.
- Alice may be the owner.
- Ben may be a billing admin.
- Chloe may be a read-only viewer.
- The Pro plan may allow exports.
- Only owners may trigger exports.
That requires both entitlement checks and permission checks.
A weak starter combines them into a single flag. A strong starter keeps them separate.
Data isolation is the heart of multi-tenancy
The most important multi-tenancy rule is simple:
A tenant should never see another tenant’s data.
That affects every query.
Safe patterns include:
- scoping records by organisation ID;
- central query helpers;
- database-level row rules where supported;
- server-side permission checks;
- audit logs for sensitive access;
- tests for cross-tenant access attempts.
Do not rely on UI route structure alone. A malicious or curious user can change IDs in URLs and API calls.
Subdomains and custom domains add routing complexity
Some B2B SaaS products use organisation-specific subdomains or custom domains. That can be powerful, but it touches auth, middleware, cookies, routing, and deployment.
Ask:
- How is the tenant resolved from the request?
- Are root-domain routes separated from tenant routes?
- Do auth callbacks work on tenant domains?
- Are cookies scoped correctly?
- Can a custom domain point to the wrong tenant?
- Does middleware leak tenant pages to the root app?
If custom domains matter to your product, do not buy a starter that treats routing as an afterthought.
Invitations need careful states
Team invitations create edge cases:
- invite sent to an existing user;
- invite sent to a new user;
- invite expires;
- invite is revoked;
- invite is accepted after role changes;
- invited email differs from login provider email;
- organisation reaches seat limit;
- inviter loses permission before acceptance.
A B2B-ready starter should either include invitations or have a data model that can support them without rewriting auth.
Audit logs become necessary in teams
When multiple people can act inside an organisation, support and compliance questions appear:
- Who deleted this record?
- Who changed the billing plan?
- Who invited this user?
- Who exported customer data?
- Who changed the role?
Audit logs are not glamorous, but they are one of the clearest signs that a starter understands business software.
Multi-tenancy audit checklist
Before using a SaaS starter for B2B, check:
- Users and organisations are separate concepts.
- Memberships support multiple users per organisation.
- Users can belong to multiple organisations if needed.
- Roles are typed or centralised.
- Permissions are enforced server-side.
- Billing entitlements are separate from roles.
- Queries are scoped by tenant.
- Cross-tenant access is tested or considered.
- Invitations are supported or easy to add.
- Admin and owner actions are logged.
- Subdomain/custom-domain behaviour is documented if supported.
- Account deletion and data export are tenant-aware.
Template Empire angle
Template Empire separates Lite, Pro, and Enterprise expectations rather than pretending every buyer needs the same architecture. A lean single-tenant foundation can be the right choice for solo products. B2B SaaS needs organisations, teams, roles, audit logs, and tenant boundaries. The important thing is to choose the right foundation before your product’s data model hardens.