Context
From 2018 to July 2022, I was Principal Software Engineer at SELISE Digital Platforms, working on Swiss Life Select's platform — a fintech product used across the EU by financial advisors and their customers to manage insurance policies, investments, and financial plans. The platform was multi-tenant and backed by microservices on an application platform-as-a-service (aPaaS) model.
I owned the frontend architecture for the platform and led the 12-member frontend team, which sat inside a wider product organization of roughly 20 people.
Problem & constraints
The platform had to serve four tenants from one product, and the tenants differed in theming, features, routing, and configuration — all four dimensions at once — without forking the codebase per tenant.
Advisors and customers also needed secure cross-service access, so single sign-on across the platform's services was a hard requirement, alongside timely delivery of updates and notifications in real time.
On top of that, this had to be a long-lived architecture: it needed to keep working as the platform grew and as the team around it changed, not just hold up for an initial launch.
Options considered
Single app with runtime tenant configuration
Rejected
One deployment serving all four tenants, switching theme, features, routing, and config at runtime based on the tenant. This kept the codebase and deployment count to one, but separate builds gave stronger isolation between tenants, so we rejected this approach in favor of that stronger isolation.
Fully separate application per tenant
Rejected
Building and maintaining four independent applications, one per tenant, would have given the strongest possible isolation. But it meant four times the maintenance burden — four codebases to patch, upgrade, and keep in sync with every shared change — and we rejected it as unsustainable.
Shared component library, separate build per tenant
Chosen
Common components and logic lived in a shared library, and each tenant got its own build produced from that library, with its own theming, feature set, routing, and configuration baked in. This gave us isolation at the build level while still reusing the code that didn't need to differ per tenant.
Decision & architecture
The core of the architecture was tenancy through separate builds on a shared component library: one shared codebase of components and logic, with four tenant-specific builds, each carrying its own theme, feature set, routing configuration, and settings. That gave every tenant its own build artifact without forking the product into four repositories.
Authentication across the platform's services used OIDC-based single sign-on inside the SPA, so advisors and customers moved across services without re-authenticating. The frontend itself was a PWA, giving advisors and customers an installable, app-like experience in the browser.
For timely updates, SignalR paired with RabbitMQ delivered live notifications into the UI in real time, with push notifications on top of that. Data-heavy views — the dashboards advisors and customers relied on to see their policies, investments, and plans — were built with Chart.js for visualizations and AG Grid for tabular data. Behind all of this, the backend ran on .NET Core microservices with MongoDB and Redis.
Outcome
The platform served more than 100,000 users across the EU on four tenant builds, all produced from one shared codebase rather than four forked ones. I owned the core frontend architecture decisions for four years, from 2018 to July 2022, and led the 12-member frontend team that built and maintained it through that growth.