The challenge: a client portal the compliance team no longer trusted
A City of London professional services firm ran a client-facing portal built on an aging framework version that had accumulated years of incremental feature additions without a corresponding architecture review. Load times averaged 6.8 seconds, which was frustrating but not, by itself, why the firm came to us. The more pressing issue was that the portal's authentication layer, built years earlier against the firm's original identity provider setup, no longer cleanly matched the SSO/SAML configuration the firm's IT and compliance teams now required, and an upcoming security review had flagged the portal as a risk area that needed remediation before it would pass.
Professional services firms in regulated sectors don't get to treat a client portal as just another web property; it handles sensitive client documents and correspondence, and a failed security review isn't a minor finding, it's the kind of thing that can affect client trust and regulatory standing. The firm needed a rebuild that solved the performance problem, since slow load times were a genuine daily friction point for client-facing staff, while also solving the deeper authentication and security architecture problem the old codebase had grown around rather than been designed for.
The approach: TypeScript and Next.js, with security architecture first
We rebuilt the portal on Next.js 15 with TypeScript throughout, chosen specifically because the firm's compliance review process required a level of type-safety and auditability in the authentication and data-handling code paths that the legacy JavaScript codebase couldn't demonstrate. Rather than treating security review as a gate to pass after the rebuild was functionally complete, SSO/SAML integration was designed first, against the firm's actual current identity provider configuration, with the rest of the application's data-fetching and rendering architecture built around an authentication layer that was correct from day one rather than retrofitted at the end.
The application runs on AWS, using the firm's existing AWS security and networking configuration rather than introducing a new hosting environment that would have needed its own separate compliance sign-off. Server-side rendering handles the document-heavy views that make up most of a client's actual portal usage, client statements, case correspondence, filed documents, which both improved load time directly and reduced the client-side JavaScript surface area that the security review needed to audit in the first place.
Implementation: the compliance review as a design constraint, not a final gate
The team worked directly against the firm's compliance and security requirements documentation from the start of the build rather than building first and adjusting for compliance findings afterward, a sequencing decision made specifically because the firm's prior experience with vendor rebuilds had been the opposite: a functionally complete rebuild that then failed review and required weeks of rework on the authentication layer specifically. Building the SSO/SAML integration first meant the compliance team could review and sign off on the authentication architecture in parallel with the rest of the rebuild, rather than at the very end when a finding would have meant reworking already-built features.
One constraint worked around during implementation was the firm's existing document-storage system, which predated the rebuild and wasn't itself in scope for replacement. Rather than migrating documents to a new storage layer, which would have expanded the project's risk surface considerably, the new portal was built to interface with the existing document store through its current access layer, hardened and audited as part of the security work, but left structurally in place. That decision kept the project scoped to what actually needed rebuilding rather than growing into a full systems migration.
Results: 2.1-second loads, security review passed, 99.9% uptime
The rebuilt portal loads in 2.1 seconds on average, down from 6.8 seconds on the legacy platform, measured across the same set of representative client-facing views under comparable conditions. The security and compliance review that had originally flagged the old portal was passed cleanly on the rebuilt version, with the SSO/SAML architecture specifically cited as meeting the standard the legacy system had fallen short of.
Since launch, the portal has run against a 99.9% uptime SLA, backed by the AWS infrastructure configuration built during the rebuild rather than an aspirational number set independently of the architecture supporting it. For a professional services firm where client trust depends partly on the reliability of the systems clients interact with directly, that combination, faster, more secure, and measurably more reliable, addressed the performance complaint and the compliance risk in the same project rather than treating them as separate problems requiring separate initiatives.
