We had a problem that many growing engineering organizations face: two core product editions, two distinct codebases, and twice the maintenance overhead. Our primary platform had evolved into separate B2C and B2B versions. While they shared common backend services, they ran on completely separate frontend applications. This is the story of how we unified our platform, the challenges we faced, and the lessons we learned about managing large-scale architectural change.

The Starting Point: Logical but Inefficient

When we first developed our platform, the initial architectural decisions made sense:

• B2C SaaS Offering hosted and managed by us, with automatic updates.
• B2B Enterprise Solution deployed and managed by the customer, focusing on custom enterprise needs.
• Shared Backend: Both versions consumed the same set of core services for business logic, authentication, and data processing.

The logic was sound, different deployment models and customer needs but as the products matured, the costs became clear:

• Duplicate Feature Development: Every UI improvement had to be built twice.
• Inconsistent User Experience: The same logical functions looked and behaved differently across deployments.
• Knowledge Silos: The codebases had evolved significantly making it difficult to share resources or build cross-functional teams.
• Testing Overhead: We had to maintain two complete and separate UI test suites.
• Design System Fragmentation: We had two parallel implementations of similar-looking components.

The Catalyst: A Unified Infrastructure

The transformation began when our infrastructure engineering team announced a new, unified container-based platform. Suddenly, the technical barriers between our two deployments were dissolving. Both product versions could now run on the same standardized orchestration layer.

This infrastructure convergence created a powerful opportunity: If our deployment models were converging, why should we maintain separate frontend codebases?

The Unified Platform Vision

We proposed a three-phase migration strategy to manage the transition incrementally, rather than attempting a risky, all-at-once rewrite.

Phase 1: Shared Component Library

Instead of immediately rewriting either frontend, we’d start by creating shared components that could be used by both the applications. This included:

• Common navigation elements
• Unified modal dialogs
• Standardized data tables
• Consistent typography and spacing

Risk Mitigation: This approach allowed us to build and test a new, unified design system in isolation without disrupting existing functionality. We could roll out changes piecemeal.

Phase 2: Progressive Feature Migration

Once the shared component library was stable and adopted, we would begin to migrate entire features one by one into a new, single-shell application. We planned the migration in order of risk:

• Start with low-risk, high-impact areas (e.g., global navigation, headers, footers).
• Move to core, read-only functionality (e.g., package browsing, dashboard views).
• Finish with complex, stateful, and deployment-specific features (e.g., user management, configuration).

Key Insight: Instead of a “big bang” replacement, we treated the migration as a series of progressive enhancements, slowly strangling the old applications in favor of the new unified one.

Phase 3: Single Codebase Deployment

The final phase would be to have the single, unified codebase as the source of truth. We would use build-time configuration to create deployment-specific builds:

• Feature flags to enable or disable functionality for our different deployment models.
• Environment-specific theming, branding, and styling.
• Deployment-specific optimization and bundling configurations.

This would give us the best of both worlds: a single codebase to maintain, but with the flexibility to serve two different deployment models and customer bases.

I will continue this next Monday. Check out my other posts from the Monday weekly series.