Next.js App Router architecture
Server Components by default, client components only where interactivity genuinely requires them. The difference shows up directly in how much JavaScript the browser has to parse.
React & Next.js Development
Frontends that load fast on a mid-range Android phone, not just on the machine they were built on.
A React frontend is easy to start and unpleasant to maintain if the early decisions go badly. State ends up spread across four libraries, every page pulls in the entire component library, and a year later a one-line copy change requires understanding six files.
The work I do here is mostly about keeping that from happening, or undoing it where it already has. That means being conservative about dependencies, keeping data fetching close to where it is rendered, and measuring the bundle rather than assuming it is fine.
What you get
Performance measured, not asserted
Core Web Vitals treated as a requirement. On this site, moving one component off the client bundle and removing a bad image preload took page weight from 976 KB to 300 KB.
Accessible by construction
Keyboard navigation, focus management, semantic landmarks and real labels. Most of this is free if it is done while building and expensive to retrofit.
Design systems that get used
Tokenised colour, spacing and type, with components documented well enough that the next developer finds them instead of writing a fifth button variant.
SEO-ready rendering
Server-rendered content, correct metadata and canonical handling, and structured data where it genuinely applies — so the page can actually be indexed for what it is about.
Testing where it pays
Component and end-to-end tests on the flows that cost money if they break: sign-up, checkout, submission. Not snapshot tests of every div.
What I build with
How the work runs
Start from the real content
Layouts designed around placeholder text break the moment a product name runs to three lines. I build against actual copy and data.
Ship a thin vertical slice
One complete route working end to end — data, loading, error and empty states — before widening. It surfaces integration problems in week one instead of week six.
Budget the bundle
An agreed size ceiling, checked in CI. Without a number, bundles only grow.
Test on a real device
A mid-range Android handset on throttled network, not a desktop simulator. It changes which decisions look acceptable.
Typical projects
Marketing sites that must rank
Statically generated, fast, with content editable without a deploy.
SaaS dashboards
Data-dense interfaces: tables, filters, charts and role-aware views that stay responsive with real row counts.
Rescuing a stalled build
Taking over a React project that slipped, stabilising it, and getting it to a releasable state.
Figma to production
Turning finished designs into components that match the file at every breakpoint, including the states designers tend not to draw.
Questions
Should we use Next.js or plain React?
If the pages need to be found in search, or the first load matters commercially, Next.js — server rendering and routing are solved problems there and rebuilding them with Vite plus a router is work without reward. If it is an internal tool behind a login where SEO is irrelevant and you want the simplest possible build, plain React with Vite is lighter and I will say so.
Can you work with our existing designers and backend team?
Yes, that is the usual arrangement. I work in your repository, your branching model and your review process. Where there is no process yet I will suggest one, but I am not going to impose my tooling on a team that already functions.
Our React app is slow. Can that be fixed without a rewrite?
Almost always, and a rewrite is rarely the cheapest route. Slowness usually traces to a handful of causes: oversized images, a client bundle carrying data that belongs on the server, re-renders from unstable props, and blocking third-party scripts. I profile first and give you a ranked list with measured savings, so you can decide what is worth doing rather than buying a rebuild.
Do you write TypeScript?
By preference, yes. On an existing JavaScript codebase I will not convert it unasked — mixed-mode migrations create their own problems. If you want to move, it is worth planning as its own piece of work with a clear order.
What happens after launch?
Handover includes a working README, documented environment variables, and a walkthrough call. After that you can take it in-house, or keep a retainer for changes. I do not build a dependency on myself into the architecture.
Related services
Tell me what you are building
A short call costs nothing, and if your project is a better fit elsewhere I will say so. Replies usually within 24 hours.
Get in touch