Frontend modernization for B2B SaaS teams
Multi-tenant dashboards, admin consoles, and plan-gated UX rebuilt to render fast for the biggest customer you have, not the demo account.
Domain context
B2B SaaS frontends fail in ways consumer apps never do. A dashboard that paints in 400ms for a brand-new trial account locks up for eight seconds when the largest paying customer logs in with eighty thousand records and a custom theme. A feature flag that gates a paywall renders correctly for the engineer testing it, but exposes the upgrade prompt to a tenant on the wrong plan. An admin console built for the founder's screenshare turns into a daily-use surface for a CS team of forty, and the workflow that used to take a developer five clicks now takes a CSM forty. Every one of these surfaces is being scaled by a different axis. Number of records, number of tenants, number of role permutations, number of plan tiers. A generic modernization that ignores those axes will look great on the demo and break in production.
Why this combination
Most modernization shops will give you a faster build pipeline, a tidier component library, and a Lighthouse score that looks good on the marketing site. In a multi-tenant B2B SaaS that's the easy half of the work. The hard half is what our engagements plan for at kickoff: a permissioning model that resolves role hierarchies in the render path without a round-trip per cell, a virtualised list that holds sixty frames per second on the largest customer's account view, a plan-gating layer that hides paid features without leaking their existence to lower-tier tenants, and a theming system that lets enterprise customers ship their own logo and brand colours without a separate build per tenant. None of that is framework code. It's decisions made early by an engineer who has shipped a B2B SaaS rebuild before.
“We rebuilt a customer-facing analytics dashboard so the largest tenant's account view loaded in under a second on the same backend, and we closed three plan-gating leaks the previous build had been silently exposing to free-tier accounts.”
Frequently asked
- CSS variables driven by a tenant config that loads at session boot, plus a small set of hard constraints on what enterprise customers can override. Usually logo, primary colour, and one accent. We push back on per-tenant component overrides; that path leads to a codebase you can't upgrade. The theming layer ships with a contrast checker that refuses to apply a brand colour that fails WCAG against the chosen background.
- A single entitlements resolver, called once per session and cached, that returns a typed object every component reads from. We don't scatter plan checks across the render tree. That pattern is how features leak to the wrong tier when the pricing page changes. Soft-paywall surfaces are designed on purpose: a feature is either fully hidden, visibly locked with an upgrade prompt, or fully available. Never partially rendered with an error.
- It looks like a product, not a developer tool. CSMs need impersonation with an audit trail of what they did while impersonating, bulk operations that handle five hundred accounts in one transaction with a clear progress and rollback story, search that holds up across millions of records, and a permission model that lets a senior CSM unblock a junior one without paging an engineer. We build the console as a first-class surface, with the same review discipline as the customer-facing app.
- Profile against the largest realistic tenant before writing a line of code. Most performance issues in SaaS dashboards come from rendering decisions made against ten-row demo data, then meeting an enterprise account with eighty thousand. We virtualise lists by default, push aggregations to the server with cursor-based pagination, defer non-critical surfaces below the fold, and treat first interactive on the worst tenant as the metric that matters.
- Almost always alongside. The engagement model is a small senior crew running the rebuild while the in-house team keeps shipping features against the existing stack. We integrate the new screens behind the same API contracts, ship them under a feature flag for one or two beta tenants, then cut traffic over progressively. The in-house team owns the rebuilt code at the end of the engagement; we're not building a system only we can maintain.