The company is buying access, not a different application
A meditation app has individual subscribers, saved sessions and a working payment flow. Then a company asks whether it can provide Premium to 500 employees for a year. This is an illustrative scenario, not a customer story. The important change is the buyer: one organization wants to pay for many people who may already use the product.
The same situation can arise for a fitness library, a learning membership or a professional writing tool. You do not need to rename your business “B2B SaaS” before responding. You need a way to represent the company’s purchase, distribute the access it includes and handle changes after the first group joins.
Building a second application is one possible response, but it is not the starting requirement. First separate the experience people use from the commercial reason they can use it. A company agreement can become an additional access source for an existing account. That distinction keeps the scope of the work visible.
Start by defining the offer
“Five hundred Premium accounts” sounds specific until someone asks who counts toward the limit. Is the buyer purchasing 500 allocated places, 500 invitations or access for anyone with a particular email domain? Can an employee leave and be replaced? What happens at the end of the year?
Write down the access terms before designing the onboarding screen. A useful first company offer identifies:
- The company buying access and the customer identifier you use for it.
- The product features or content collections included.
- The number of people who can hold a place under the agreement.
- When access starts and, if applicable, when it ends.
- Who may choose those people and make later roster changes.
- What happens to personal subscriptions held by participating users.
These are product and commercial decisions, not all database fields. Your contract and invoice remain in the systems that own them. The access layer needs a faithful operational representation of the agreed terms; it does not become the legal agreement merely because it records a start date and a seat limit.
For example, an education product might sell one course collection to a department without including every course available to individual subscribers. Naming the included features explicitly avoids making a broad “paid” flag carry several different meanings.
Why individual subscriptions are not enough on their own
A personal subscription connects a payer to a person’s access. A company purchase also needs to connect a buyer to a pool of places and to the people using those places. Copying the same subscription state onto every employee account loses the agreement that explains why those accounts are entitled to access.
It also makes ordinary changes awkward. The company renews with fewer seats. An employee leaves halfway through the term. A customer administrator replaces the original buyer. Those changes should operate on the relevant company agreement or allocation, not require someone to reconstruct a purchase from unrelated account flags.
Your billing provider can continue collecting money. Define the mapping from commercial payment state to access state deliberately: what activates an agreement, what renewal changes and what should happen during a payment problem. Do not assume that a successful payment alone answers which people may use which features.
Keep the account people already recognize
The existing application should remain responsible for sign-in, profiles, saved work and its own user identifier. When someone accepts company access, connect it to that identity after authentication. Avoid issuing a second account merely because a different party is paying.
For a wellness app, this can mean that the person keeps the profile they already use while gaining access funded by their employer. It does not imply that the employer receives their activity, private content or personal billing information. Data visibility is a separate product decision; buying seats is not blanket permission to inspect employees’ use of the application.
Use a stable internal user ID for the connection. Email can help deliver an invitation, but addresses can change and people can have more than one. Treating email as the permanent seat identity makes later account changes harder to reason about.
If someone signs in to the wrong account while claiming an invitation, make the choice visible before completing the claim. Account linking should follow your application’s identity-verification rules, not an automatic merge based on similar-looking email addresses.
Make company access a separate source
A person may have an active personal subscription and a valid company allocation at the same time. For a feature that either source provides, your application can choose to allow access if either remains valid. The policy belongs to your product; it should be explicit rather than an accidental consequence of the last webhook received.
Do not replace “personally subscribed” with “company member” in one mutable field. Preserve each source and ask what remains valid when one ends. If the company agreement expires, a continuing personal subscription should still be considered. If the personal subscription ends, current company access may still provide the feature.
Access and charging are different decisions. Receiving an employer-funded seat does not automatically mean cancelling or refunding a personal subscription. Decide what to offer the person, explain it in the interface and implement any billing change through the system that owns that subscription. The separate guide on company-paid access and individual subscriptions explores this boundary in more detail.
Model places separately from people
A seat is an allocation under an agreement, not the person’s account. It connects a company, a particular package of access and an external user. This lets you release a place without deleting a profile, saved progress or historical activity in your application.
Give each allocation its own identity and history. If an employee leaves and later returns, the later allocation can be distinguished from the earlier one. That is useful for explaining a disputed access change without pretending the person themselves was recreated.
Capacity must be enforced when an allocation is committed. A screen showing “one seat left” is useful guidance, but two administrators can act on that screen at the same time. The component responsible for seat allocation must prevent both operations from consuming the same final place.
Keep the different counts clear. A roster may contain invitations that have not been accepted, users holding more than one package, and allocations whose agreement is no longer valid. A count of registered users, allocated seats or current feature access answers a different question. The seat-based licensing guide goes deeper into those distinctions.
Choose an onboarding path the company can use
There is no single best way for every company to bring its people in. Match the path to what the buyer knows and what your application can verify.
- Direct assignment works when your backend already knows the intended user IDs.
- A roster import helps your operators allocate a known group, with review of duplicates and unavailable capacity before submission.
- Email invitations work when the company knows who should receive a place, but those people need to sign in or create an account first.
- An access code can be useful when the company distributes the claim mechanism itself, with explicit expiry or redemption limits where supported.
Whichever path you choose, the person still authenticates in your application. The invitation or code is a credential for claiming access, not a replacement identity system. Keep sensitive claim tokens out of analytics, support screenshots and ordinary application logs.
Be precise about when capacity is consumed. Sending an invitation need not reserve a place. If allocation happens at redemption, the interface should explain that a later claim can fail because the agreement expired or its available seats were used. Do not promise a reservation your system has not made.
Give the customer administrator a bounded job
The company knows when an employee joins or leaves. A customer administration surface can let an authorized person handle routine invitations and seat changes rather than sending every request to your support team.
Delegation needs a boundary. Managing one company’s people should not grant control over your product’s features, API credentials, other customers or commercial limits. Your team should still decide which agreements exist and who may administer each company.
Separate employee access from administrator access too. An employee receiving a seat does not automatically become a customer administrator. An administrator may manage the roster without using the employee-facing application. Explain both roles so the buyer knows which invitation to expect and where to sign in.
A practical support view should answer which company and agreement were involved, which allocation changed, who initiated it and when. This is more useful than a single “Premium enabled” indicator when the customer asks why one employee can no longer enter the product.
Check access where the feature is used
Your backend should make the access decision using the authenticated user’s stable ID and the feature being requested. The client may display the result, but hiding a button is not enforcement for a protected backend action.
For a reading product, the feature might represent a premium library. For a professional tool, it might represent exports. The commercial package can change while the product continues asking about the same capability. This avoids spreading contract names and company-specific exceptions throughout application code.
Company-access infrastructure can resolve its own current access sources. Your application still combines that result with any personal subscription rules and other product restrictions it owns. Decide how unavailable checks, caching and stale information should behave. Do not silently turn a timeout into a confident answer that someone has no valid access.
Move from individual-only access in stages
You do not need to migrate every subscription or rebuild every feature gate before learning whether the company model works. Choose a bounded path that you can observe and reverse at the integration boundary.
- Define one company offer and one representative included feature.
- Map the company record and a controlled user through existing identifiers.
- Connect the company-access check beside the current personal-access check.
- Verify each source alone, both together and neither source remaining valid.
- Add the chosen onboarding path and test a departure or replacement.
- Delegate customer administration only after the limits and support path are clear.
During rollout, compare the new decision with the existing behavior where practical before changing enforcement. Investigate mismatches rather than treating every difference as an error in the old system. Some reflect product-policy choices that were never written down.
Document which system owns each transition. The access layer might release a company seat, while your billing system owns personal cancellation and your authentication system owns account recovery. Keeping those responsibilities separate makes recovery less likely to damage an unrelated part of the person’s account.
Avoid these shortcuts
Creating work-only duplicate accounts shifts complexity onto users and support. Combining all paid access into one boolean hides which source is still valid. Using email-domain membership alone as proof of purchased access can grant more than the buyer agreed to distribute.
Deleting seat history on departure removes evidence needed to explain changes. Treating a roster preview as a reservation fails under concurrency. Giving customer admins project-wide credentials turns a narrow operating role into a much broader authority.
None of these shortcuts is necessary to accept the first company deal. A small model with clear identity, allocation and access boundaries is a better starting point than an elaborate portal with unclear rules underneath it.
Where Business Mode fits
Business Mode provides a company-access layer around the application you already operate. An Organization represents the company. A License records the access terms: included Entitlements, seat capacity and validity. Assignments connect external users to seats; the backend access check resolves the current company-provided feature access.
It also supplies invitations, access codes, customer administration and operational history. In Business Mode, customer admins can review their company’s licenses and members, create invitations and codes, and release seats within their authority. Direct and bulk roster operations remain with your backend and developer control plane.
Your application keeps customer authentication, profiles, feature enforcement and its personal-subscription policy. Business Mode does not automatically cancel existing subscriptions or turn a License into a legal contract. This separation is useful when company agreements, team changes and delegated administration are becoming a distinct system to operate; a genuinely simple offer may need less infrastructure.
Explore the consumer-app use case and customer administration for the product view. When the model fits, use the Quickstart to connect the first company-access path.