Scaling a benefits platform to support multiple enterprise clients

The problem

BenPal started as a single-client employee benefits platform. Success with the initial client led to demand from other enterprises, each expecting a fully branded experience that looked like their own internal system.

More than just logos

Enterprise clients had requirements beyond simple logo swaps:

• Complete visual identity (colours, typography, imagery)
• Client-specific terminology and language
• Different feature sets based on their benefit programmes
• Unique workflows matching their HR processes
• Custom integrations with their existing systems

The complexity

Building separate codebases per client was not sustainable:

• Maintenance burden: Bug fixes and enhancements needed applying to every instance
• Release coordination: Different clients on different versions created testing nightmares
• Resource constraints: Each new client would require proportionally more development effort
• Time to market: Enterprise sales cycles demanded rapid onboarding once contracts signed

The business needed a single codebase that could present as multiple distinct applications.

Our approach

We designed a comprehensive white-label architecture that separated presentation from functionality, allowing each client to have a unique experience from a shared platform.

Dynamic CSS with Less compilation

Rather than pre-building CSS for each client, we implemented just-in-time compilation:

• Client brand variables (colours, fonts, spacing) stored as configuration
• Less stylesheets referenced these variables
• CSS compiled on-demand and cached when clients accessed the platform
• Brand changes deployed without code releases

Feature toggle framework

Client-specific functionality was managed through a granular toggle system:

• Module-level toggles: Enable or disable entire features (e.g., voluntary benefits)
• UI toggles: Show or hide specific interface elements
• Workflow toggles: Include or skip steps in multi-stage processes
• Integration toggles: Connect to client-specific external systems

Toggles were hierarchical - enterprise clients could have different configurations for subsidiary companies.

Configuration-driven architecture

Client settings lived in the database, not code:

• Brand assets (logos, images) uploaded through admin interface
• Terminology mappings (e.g., "Benefits" vs "Perks" vs "Rewards")
• Email templates with client-specific content
• Help content and documentation per client

Implementation

• Designed tenant identification from subdomain and authentication context
• Built admin tools for client onboarding and configuration
• Created preview capability for brand changes before publishing
• Implemented caching strategy balancing freshness with performance
• Established testing patterns covering multi-tenant scenarios

Outcomes

Scalability

• Approximately 10 enterprise clients supported during the beta programme
• Single codebase with no client-specific branches
• New client onboarding measured in days, not months

Consistency

• Bug fixes applied once and benefited all clients
• Feature enhancements rolled out progressively across client base
• Core platform quality improved as client count grew

Client satisfaction

• Fully branded experiences - end users often unaware they were on a shared platform
• Rapid response to brand change requests
• Features could be enabled incrementally as client needs evolved

Development efficiency

• Single test suite covering all clients through parameterisation
• Reduced regression risk from parallel codebases
• Team focused on platform capabilities rather than client maintenance

Business growth

• Shortened enterprise sales cycle with proven multi-tenant capability
• Reduced marginal cost of each new client
• Platform became more valuable with each enterprise onboarded

Tenant resolution

Each request needed to resolve which client context to use:

Request → Subdomain Parsing → Tenant Lookup → Context Injection
          (client.benpal.co.uk)    (Database)     (Request Scope)

The tenant context was available throughout the request pipeline, influencing:

• Which brand assets to serve
• Which feature toggles to evaluate
• Which configuration values to apply
• Which integrations to invoke

Less JIT compilation strategy

Dynamic CSS generation required careful performance optimisation:

1. First request: Compile Less with client variables, cache result
2. Subsequent requests: Serve cached CSS directly
3. Brand update: Invalidate cache for affected client
4. Deployment: Optional pre-warming of caches for all clients

Cache keys incorporated both client identifier and stylesheet version, enabling safe deployments while maintaining cache efficiency.

Feature toggle patterns

Toggles were evaluated at multiple levels:

Platform Default → Client Override → User Group Override → User Override

This hierarchy allowed:

• Platform-wide feature flags for progressive rollout
• Client-specific feature enablement based on contracts
• Pilot groups within clients for testing
• Individual user overrides for support scenarios

Multi-tenant testing

The testing strategy addressed the combinatorial complexity:

• Unit tests: Core functionality tested without tenant context
• Integration tests: Parameterised tests run against multiple tenant configurations
• Visual regression: Screenshot comparison for each client's branded experience
• Contract tests: Verified integrations for each client's external systems

Lessons learned

• Cache invalidation is genuinely hard - invest in tooling to trace cache state
• Feature toggles accumulate technical debt - establish lifecycle management early
• Enterprise clients will request "just one small customisation" - have a clear framework for what is and is not configurable
• Multi-tenant bugs are subtle - reproduce issues in the specific client context, not just development defaults