Scaling a Benefits Platform to Support Multiple Enterprise Clients
How we architected a white-label solution with dynamic branding and per-client feature configuration
Key results at a glance
The challenge
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.
The results
Key results
- Single codebase supporting approximately 10 enterprise clients in beta
- Dynamic branding without code deployments through Less JIT compilation
- Feature toggles enabling per-client functionality configuration
- Client onboarding reduced from months to days
- Architecture established foundation for continued platform growth
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
The solution
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
Technical deep dive
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:
- First request: Compile Less with client variables, cache result
- Subsequent requests: Serve cached CSS directly
- Brand update: Invalidate cache for affected client
- 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
Ready to achieve similar results?
Let's discuss how we can help your organisation achieve these results.
Book a strategy call