Payments portal rebuilt from the ground up

Our client operates a payments platform where businesses manage their payments and accounts. The legacy client portal had reached the end of its life - dated tooling and structural constraints that made it progressively harder to evolve. This was never scoped as a reskin. They wanted a genuinely new product: rebuilt architecture, rebuilt services underneath it, and a front end their own team could keep extending. We were brought in to build it alongside them.

We worked inside the client team rather than beside it as a separate delivery unit. Architecture first: the structure of the application and the services it depends on were settled before interface work began. A custom design system: no off-the-shelf component library. Components were built for the client and owned by the client. Accessibility in the foundation: React Aria as the behavioural layer beneath every component, so keyboard handling, focus management and ARIA semantics are inherited rather than retrofitted screen by screen. Type safety end to end: TypeScript across the application. Data and forms: TanStack for server state, data-dense views, and validation-heavy flows. Delivery pipeline from day one: GitHub Actions for automated testing, builds and controlled deployments, rather than a pipeline bolted on once the product was written. We used AI-assisted development throughout to move faster on a rebuild of this size. That is a delivery choice, not a product claim - the portal itself ships no AI features.

A new payments portal, built from scratch and now running as the default. A custom design system on React Aria primitives - the client owns the component layer outright, so interaction behaviour stays consistent across the product and is not tied to a third party roadmap. TanStack Query for server state and caching, Table for the data-dense views payments operations demand, Form for complex submission and validation flows. TypeScript throughout, from the data layer to the interface. GitHub Actions pipelines covering tests, linting, builds and controlled release to production.

The new portal replaced the legacy one outright and is the portal the client base uses today. The client team owns a design system and front-end architecture they extend themselves, without legacy constraints. Accessible interaction behaviour is built into the component layer rather than added per screen. The CI/CD standard set on this build became the reference for later platform work across the organisation. We continue to maintain and extend the portal as the product evolves. What this engagement demonstrates: we can replace a business-critical interface in a regulated environment without a rewrite that strands the internal team - the architecture, the component layer, and the pipeline are theirs at the end of it.