Most SaaS companies start with a single product. One codebase, one database, one billing plan. It works beautifully until the business grows and leadership wants to launch a second product. Then a third. Suddenly the team is staring at a monolith that was never designed to support multiple products, and every shortcut from year one is now a structural problem.
We have built and migrated multi product SaaS platforms across several industries, and the pattern is always the same: companies that plan for multi product architecture early save months of rework later. Companies that bolt it on after the fact end up with tangled data models, duplicated auth systems, and billing logic scattered across dozens of files.
This post covers the architectural decisions that matter when building a SaaS platform designed to support multiple products from day one, or when retrofitting an existing single product system to support more.
Why Multi Product Architecture Is Different
A single product SaaS is straightforward. You have users, you have accounts or organizations, and you have one set of features behind one paywall. The data model is flat. The billing logic maps cleanly: one subscription equals one set of permissions.
Multi product changes the equation. Now you need to answer questions that did not exist before. Can a user subscribe to Product A without Product B? Do products share the same user accounts? Is data from Product A visible inside Product B? Can an organization have different team members on different products?
These are not hypothetical questions. They are decisions that affect your database schema, your auth layer, your billing integration, and your frontend routing. Getting them wrong means rebuilding core infrastructure later, and that rebuild will happen while your existing users are actively using the platform.
The fundamental architectural choice is between a shared everything model (one codebase, one database, products are feature groupings) and a shared nothing model (separate codebases and databases per product, connected by a common identity layer). Most successful multi product platforms land somewhere in between.
The Shared Identity Layer
Regardless of how isolated or integrated your products are, they need to share one thing: user identity. Users should sign in once and access every product they are subscribed to. This means a centralized auth system that sits above all individual products.
In our experience, this identity layer needs to handle:
- Single sign on across all products
- Organization management with roles that can vary per product
- Session management that works across subdomains or separate domains
- User provisioning so that when a user is added to an organization, they can be granted access to specific products
We typically implement this as a dedicated auth service or schema that all products reference. On projects built with Supabase, this maps naturally to the built in auth system with custom claims in the JWT that encode which products and roles a user has access to. The key is that no individual product owns the user record. The identity layer does.
If you are evaluating your backend stack for this kind of system, our Supabase vs Firebase comparison covers the tradeoffs for auth and data isolation in detail.
Database Architecture: Schemas, Not Databases
The temptation with multi product is to spin up a separate database per product. This feels clean in theory, but it creates massive operational overhead. Cross product queries become impossible. Shared entities like users and organizations end up duplicated. Migrations multiply. Monitoring complexity explodes.
The better pattern for most teams is schema based isolation within a single database. Each product gets its own schema (or set of schemas) with its own tables, functions, and policies. Shared entities live in a common schema. Foreign keys connect product specific data back to shared records.
This gives you:
- Logical isolation without operational duplication
- Cross product queries when you need them (reporting, admin dashboards)
- Single migration pipeline with per schema organization
- Row level security that enforces product boundaries at the database level
The schema layout we have used on production multi product systems typically looks like this:
- `common` schema: users, organizations, memberships, product entitlements
- `product_a` schema: all tables specific to Product A
- `product_b` schema: all tables specific to Product B
- `billing` schema: subscriptions, invoices, usage records, mapped to products
Each product schema references `common.organizations` and `common.users` but never references another product schema directly. This boundary is critical. If Product A starts joining against Product B tables, your isolation is gone and decoupling later becomes a migration nightmare.
For a deeper look at how database schema design patterns support this kind of structure, we have written about the foundational concepts separately.
Billing Across Products
Multi product billing is where most teams underestimate the complexity. The naive approach is one Stripe subscription per product. That works until you need to offer bundles, apply cross product discounts, or handle cases where upgrading Product A should automatically adjust the price of Product B.
The pattern we recommend is an entitlement based billing model. Instead of tightly coupling Stripe subscriptions to feature access, you maintain an entitlements table that maps what each organization has access to. Stripe subscriptions feed into this table via webhooks, but the entitlements table is the single source of truth for feature gating.
This decoupling means:
- You can grant access manually (sales deals, partnerships) without touching Stripe
- Bundle pricing is a billing concern, not a feature access concern
- Upgrading or downgrading a single product does not require rewriting access logic
- Free trials per product are simple: insert an entitlement with an expiration date
Your payment processing infrastructure should handle Stripe webhooks for subscription lifecycle events and update the entitlements table accordingly. The application code only ever checks the entitlements table, never Stripe directly.
Frontend Architecture: Shared Shell, Product Modules
On the frontend, multi product SaaS needs a shell that handles navigation, auth state, and product switching, with individual product UIs loaded as modules or routes within that shell.
The two practical approaches are:
Monorepo with shared packages. All products live in one repository. Shared UI components, auth hooks, and API clients live in shared packages. Each product is a separate app or route tree. This works well for teams under 30 engineers and keeps the deployment pipeline unified.
Micro frontend architecture. Each product is a separately deployed frontend application, stitched together at runtime by a shell application. This adds significant infrastructure complexity but allows fully independent deployment and technology choices per product. We generally only recommend this for teams that have hit real scaling pain with the monorepo approach.
For most growing SaaS companies, the monorepo approach with a shared component library is the right call. It keeps developer velocity high, reduces context switching, and avoids the distributed systems problems that micro frontends introduce.
Feature Gating Without Spaghetti
With multiple products, you need a clean way to check what features a user can access. The worst pattern is scattering `if (user.plan === 'pro')` checks throughout the codebase. This couples your UI to specific plan names and makes every pricing change a code change.
Instead, use a permissions and entitlements abstraction. Define capabilities like `can_use_analytics`, `can_export_data`, `max_team_members`, and check those. The mapping from plans to capabilities lives in one place, usually a configuration table or a feature flag system. When you launch a new pricing tier or restructure bundles, you update the mapping, not the application code.
We covered this pattern in depth in our post on designing user roles and permissions for SaaS, which applies directly to multi product setups.
When to Invest in Multi Product Architecture
If you are building your first product and have not validated product market fit, do not build multi product infrastructure. Build a clean single product SaaS with good separation of concerns. The investment in multi product architecture pays off when:
- Your business strategy explicitly includes a second product in the next 12 months
- You are seeing demand for adjacent features that do not fit your current product scope
- Your current product has natural segmentation points that suggest splitting
The cost of building multi product architecture from day one is roughly 20 to 30 percent more upfront development time. The cost of retrofitting it later is 3 to 6 months of migration work on an active production system. In our experience, the upfront investment is almost always worth it if a second product is on the roadmap.
If you are planning a multi product platform and want to get the architecture right from the start, we specialize in exactly this kind of system architecture work. Reach out to us and we will map out the right approach for your specific situation.