Frontend and web applications

Dashboards, back-offices and web applications in React and Next.js. Built as a component system, with performance and accessibility measured rather than promised.

Front-ends rot fast. They start clean, gain screens, gain exceptions, and two years later changing one button means touching seven files. Meanwhile the page puts on weight, phones suffer, and nobody is measuring.

A React or Next.js application organised into reusable components, with predictable state, load times measured against Core Web Vitals, and keyboard and screen-reader accessibility. Tested end to end, in the browser, the way a user uses it.

It makes sense when the application has many similar screens, when the team has grown and everyone solves things their own way, or when it is slow and nobody can point at where.

React and Next.js applications

A complete web application, with rendering chosen per page to fit the case — static where it can be, server-side where it has to be. Routing, forms, permissions and state solved one single way.

Component library

A documented set of components with the states designed in: empty, loading, error, no permission. It is what makes the tenth screen cost less than the first.

Legacy front-end modernisation

Replacement in parts, with the old system and the new one living side by side, rather than a year-long rewrite with a date on it. Each migrated piece goes to production as it lands.

Performance and Core Web Vitals

Measure before optimising: what is image weight, what is too much JavaScript, what is data fetched at the wrong moment. Then fix it, with a number before and after.

Accessibility

Keyboard navigation, contrast, visible focus, screen readers and HTML that means something. Beyond being the right thing, it is what makes the system work for someone who spends eight hours in it.

End-to-end testing

The paths that cannot break become tests that run in the browser on every change. It is what lets you touch what is already live with confidence.