The Architecture Decisions That Set the Ceiling on Your B2B2C Platform

Most architecture decisions in a B2B2C platform are reversible. Data models can be migrated, UIs can be rebuilt, and integrations can be swapped. A small number of foundational choices work differently. Getting them wrong does not create technical debt. It creates a ceiling you cannot build past without a full rewrite.

These decisions matter not because they are technically complex but because they touch every layer of the platform simultaneously. Changing them at scale means migrating auth systems, reworking schemas, rerouting URLs embedded in customer emails and third-party integrations, and rebuilding admin surfaces.

The decisions that are expensive to change at scale

• Tenant isolation model: whether data is isolated at the row level by organizationId from day one, or added as a filter later when the first enterprise customer asks for it.
• Identity separation: whether org staff accounts and portal customer accounts have separate auth systems and credential lifecycles, or share the same auth table separated only by a role flag.
• Portal tenancy model: whether the portal resolves tenant identity from the host (tenant.yourportal.com) or from the path (/portal/tenant-id). Switching later breaks every external link, email template, and customer bookmark.
• Permission hierarchy: whether roles are flat per-user flags or a scoped, hierarchical model that supports platform admin, org staff, and portal customer tiers independently.
• Audit and activity log: whether mutations are logged at the write layer from day one, or added retroactively when compliance or debugging demands it. Retroactive audit logging requires touching every write path in the codebase.

None of these are hard to get right before the first operator goes live. Every one of them is expensive to change after. That is the real cost of underscoping a B2B2C build.