React and Next.js development
React is not a decision any more; it is the default, and the interesting questions have moved one level up. What renders where, what ships to the browser, and what your rendering strategy is doing to your Core Web Vitals.
Discuss your projectWhen we reach for it
- Applications with substantial interactive state — dashboards, editors, configurators, multi-step workflows
- Products that need per-user server rendering close to the database
- Teams that already have React capability and need to stay hireable
- Anywhere a design system in code is going to be shared across surfaces
When we don’t
- Content-led marketing sites, where Astro ships almost no JavaScript and is materially faster
- Simple brochure sites that a well-configured CMS theme covers for a fraction of the cost
- Interfaces that are essentially a form and a table, where a server-rendered page is simpler and cheaper to maintain
This half is the useful one. A firm that has never declined to use a technology has never chosen one.
What we have learned about the parts of React & Next.js that bite — written from projects rather than from documentation.
Rendering strategy is the real decision
Next.js gives you static generation, server rendering, incremental revalidation and client rendering, and the temptation is to pick one and apply it everywhere. That is how you end up either server-rendering a page that never changes, or client-rendering a page that a crawler needed to read.
We decide per route. Content identical for everyone is generated at build time and served from a CDN. Content that varies by user is rendered on the server. Only genuinely interactive regions ship JavaScript. That split is why the pages we build tend to pass Core Web Vitals without a performance sprint at the end of the project.
Where React projects actually go wrong
Not in React. They go wrong in state management — specifically in confusing server state with client state. Data that lives in your database and is cached in the browser is not application state, and managing it with the same tools produces stale data, duplicated fetches and a great deal of code that exists only to synchronise things.
The second failure is the component library that grew by accident. Screens built first, patterns extracted later, and forty-four slightly different buttons by month nine. Tokens and primitives first is dull advice that saves a redesign.
Server Components, pragmatically
React Server Components genuinely reduce the JavaScript a browser has to run, and for data-heavy pages the difference is real. They also introduce a boundary that developers get wrong, and debugging across it is harder than debugging either side of it.
Our position is to use them where the win is measurable — data-dense pages, large dependency trees kept off the client — and to keep the boundary in a small number of obvious places rather than scattered through the tree. Being able to point at where the line is matters more than being clever about where it goes.
React and Next.js, applied
The shapes of system this technology is actually good at, rather than the ones it is capable of.
Usually alongside
- TypeScript
- Next.js App Router
- TanStack Query
- Zod
- Tailwind CSS
- Radix UI
- Playwright
- Vercel
- Operational dashboards and admin systems
- Customer and partner portals with real permission models
- SaaS product interfaces with multi-tenancy
- Design systems and component libraries shared across products
- Content sites where rendering strategy decides the performance budget
React & Next.js, answered
Should we use Next.js or plain React?
Next.js, in almost all cases. A plain React single-page application means building routing, data loading, code splitting and any server rendering yourself, which is work you will do worse than the framework does and will then maintain forever. The exception is an application that lives entirely inside an authenticated shell with no SEO requirement and no server rendering need — an internal tool behind a login — where a simpler client-rendered setup is genuinely less machinery.
Is React good for SEO?
It depends entirely on rendering strategy, which is why that decision matters more than the framework. A client-rendered React app serves an empty shell and hopes the crawler executes JavaScript — Google often does, other crawlers and AI summarisers often do not, and it costs you crawl budget either way. Server-rendered or statically generated pages serve real HTML and have no such problem. We decide this per route, and for purely content-led sites we frequently recommend Astro instead, which is what this site uses.
Can you work on our existing React codebase?
Yes. We start with an assessment covering dependency health, the state management approach, the testing situation and bundle size, and you get a written list of issues ranked by cost to fix against benefit. The most common findings are the same two things: server state managed as if it were client state, and a component library that grew by accident rather than by design. Both are fixable incrementally, which matters, because nobody can afford to stop shipping while a front end is rearranged.
What about React Server Components?
We use them where the win is measurable — data-dense pages and heavy dependency trees kept off the client — and we keep the server/client boundary in a small number of obvious places. They genuinely reduce shipped JavaScript. They also introduce a boundary developers get wrong and which is harder to debug than either side of it, so scattering it through the component tree buys complexity that outweighs the benefit. Being able to point at where the line is matters more than being clever about where it goes.
Where this shows up
- BuildWeb Application DevelopmentDashboards, portals and internal tools that hold up under real data volumes — not a prototype that falls over at ten thousand rows.Read more
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- GrowUI/UX DesignProduct design and design systems. Usually the first thing that turns out to be wrong, and the cheapest thing to fix.Read more
Building with React & Next.js?
Whether it is a new build, a takeover or a second opinion on an architecture someone else chose — the first conversation is free and we will tell you if the stack is wrong for the job.