B2B SaaS Starter Architecture: What to Get Right Before Launch

B2B SaaS architecture is mostly about avoiding expensive changes later. The first version can be simple, but the foundation needs room for teams, billing, support, compliance, and enterprise requests.

This is the baseline architecture we recommend before launch.

Model the Customer as an Organization

Even if the first buyer is a single founder, create an organization record. A user can own or belong to one or more organizations, and product data belongs to the organization.

That gives you a clean path for:

• Inviting teammates.
• Changing ownership.
• Billing the company instead of a person.
• Showing organization-level analytics.
• Adding SSO later.
• Exporting or deleting organization data.

Do not attach every important record directly to userId unless it is truly personal.

Separate Platform Roles from Organization Roles

There are two different permission systems:

• Platform role: what a user can do across the whole app.
• Organization role: what a user can do inside one customer workspace.

An admin support user may be a platform admin without being a member of every customer organization. A customer owner may control billing and members for one organization without seeing platform admin screens.

Keep those concepts separate.

Billing Should Reference the Organization

Subscription records should be able to point at the paying organization. A B2B customer may have many users, but one billing relationship.

The subscription layer should store:

• Provider.
• Customer ID.
• Subscription ID.
• Plan ID.
• Status.
• Seat count.
• Seat cap.
• Current period.
• Trial end.
• Cancellation state.

This lets your app render billing state without calling the payment provider on every request.

Screenshot placeholder: billing screen with enterprise plan, seat count, and renewal date.

Admin Support Needs Its Own Workflows

Customer-facing product screens are not enough. You need internal tools for:

• Finding a user.
• Checking subscription state.
• Reviewing recent activity.
• Retrying failed webhooks.
• Toggling features.
• Investigating errors.
• Exporting data.

If support has to query the database manually, your product is not ready for scale.

Audit Logs Should Start Small but Early

Audit logs do not need to capture every click. Start with actions that affect security, billing, permissions, and customer data:

• User role changed.
• Member invited.
• Member removed.
• Subscription changed.
• SSO configured.
• API key created.
• Webhook retried.
• Data export requested.

Add metadata, IP address, actor, resource, and timestamp. That is enough for many support and compliance questions.

Feature Flags Need Ownership

Feature flags are not only for experiments. They protect launches.

Use flags for:

• Rolling out risky product changes.
• Enabling modules for specific customers.
• Testing new pricing.
• Hiding unfinished integrations.
• Responding quickly when a feature misbehaves.

Every flag should have a name, description, enabled state, and rollout percentage.

Webhooks Need Delivery State

If your SaaS sends events to customers or receives billing provider events, you need delivery records.

Track:

• Target URL.
• Event type.
• Status code.
• Attempts.
• Next retry time.
• Response body.
• Error message.
• Dead-letter state.

Webhook failures are normal. Invisible webhook failures become support incidents.

Analytics Should Be Organization-Scoped

For B2B SaaS, product analytics should answer organization-level questions:

• Which accounts are active?
• Which features are used?
• Which pages drive activation?
• Which users are blocked?
• Which plans generate the most usage?

Store organizationId on events when possible. User-level analytics alone is not enough.

Final Shape

A strong B2B SaaS starter has a clear spine:

• Users authenticate.
• Users belong to organizations.
• Organizations own product data.
• Organization members have roles.
• Subscriptions attach to organizations.
• Admin workflows operate the platform.
• Audit logs explain sensitive changes.
• Analytics and webhooks are organization-scoped.

That architecture is still lean, but it will survive the first enterprise customer.