React + Next.js development — for product teams and agencies worldwide

React apps that load fast, scale clean, and your team can actually ship on.

Custom React and Next.js development for product teams and Shopify-backed brands. We ship apps that load in under 1.5 seconds, pass WCAG 2.2 AA, keep client JavaScript under 150 KB on first load, and a mid-level React engineer can pick up on day one.

1,000+
React apps shipped since 2015
10yrs
Building on React & Next.js
4.9
Across 1,000+ reviews
150KB
Initial JS budget · every build
The real cost

A slow, bloated, or wrong-stack React app is a tax you pay every sprint.

Most product teams discover their React app is hurting them only after the codebase has been in production for a year — performance has degraded, bundle size has crept past a megabyte, the team has slowed down without anyone noticing, and the architecture decisions made on day one are now expensive to undo. The three observations below are what we say out loud on every React discovery call.

01

A slow React app loses users before they see it.

Every additional second of mobile load time costs roughly 7% of conversions. A typical Create React App with popular libraries (Material UI, lodash, moment, three.js, charting libs) ships 600 to 900 KB of JavaScript on first load. On a real mobile network that means 3 to 5 seconds before the user sees anything. The app does not crash — it just loses people. Most teams have no idea because Chrome on a developer's desktop hides the problem.

02

Bad architecture decisions on day one echo for years.

Picking CRA when you needed Next.js. Picking Next.js when you needed Vite. Skipping TypeScript. Skipping a design system. Skipping accessibility. Each shortcut feels cheap on day one and gets dramatically more expensive every sprint after that. We have inherited many React codebases where the founder's first engineer made one architecture call in week two that cost the company eighteen months of work to undo. The right architecture decisions, made on day one, are the cheapest engineering investment a team can make.

03

A React app that only your senior engineer can ship on is a liability.

Most React apps we inherit have grown around the patterns of whoever wrote the first thousand lines. The patterns are clever but the next engineer cannot pick them up without a multi-week onboarding. Bus factor of one is a real cost — a senior engineer leaves, the team slows down for months. Apps we build are explicitly architected so a mid-level React engineer can pick up the codebase on day one and ship by day three. That is not a sacrifice — it is the discipline that compounds for years.

What we build

Six kinds of React build, each architected to last.

Next.js builds (App Router)

Marketing sites, content engines, e-commerce frontends, and product apps where SEO and first-load matter. App Router with Server Components, streaming, Server Actions, deployed to Vercel or Cloudflare Pages.

Custom React apps (Vite)

SaaS dashboards, internal tools, real-time apps where the UI is the product. Vite + React Router + TanStack Query + TypeScript + a design system. Built for product teams that need to ship fast and stay shipping for years.

SaaS dashboards & product UI

Logged-in interfaces with charts, tables, real-time updates, complex forms. Design-system-driven (Radix, React Aria, Shadcn). Accessible by default. Built so a mid-level engineer can pick up the codebase and ship by day three.

Headless commerce frontends

Shopify Hydrogen + Oxygen storefronts, Sanity / Contentful-driven content sites, custom GraphQL-backed product catalogues. React storefronts where the commerce engine sits behind an API and the frontend is yours to architect.

Marketing sites (Next.js / Astro)

SaaS marketing sites, content engines, agency portfolios where SEO matters and Core Web Vitals are a competitive axis. Next.js for editorial + product mix; Astro for content-heavy sites with minimal interactivity. Sub-1.0-second LCP achievable on every page.

Migrations (CRA → Vite, Pages → App Router)

Create React App migrations to Vite (1 to 3 weeks, typically 20-40% performance lift). Pages Router to App Router migrations (4 to 12 weeks). Vanilla React to Next.js (6 to 16 weeks, effectively a rebuild). We have done each many times and will tell you when migration is the right call versus optimising what you have.

Beyond the build

The work that keeps the React app healthy after launch.

A React app is healthy only as long as someone is paying attention to the bundle, the dependencies, and the architecture. We offer three engagement types alongside the build itself — for teams migrating from older React stacks, for teams that need ongoing engineering after launch, and for teams setting up the DX and CI foundations that compound over years.

React migrations

Create React App to Vite migrations (1 to 3 weeks, 20-40% performance lift). Pages Router to App Router migrations (4 to 12 weeks). Class-component to hooks. Older state libraries (Redux, MobX) to modern equivalents (Zustand, TanStack Query). Done carefully so the team keeps shipping product through the migration.

  • CRA → Vite (1-3 weeks, immediate perf lift)
  • Pages Router → App Router (4-12 weeks)
  • JavaScript → TypeScript (file-by-file)
  • Old state → modern state (Zustand, TanStack Query)

Performance audits & ongoing engineering

Monthly retainers covering dependency updates, Core Web Vitals monitoring, bundle-size monitoring, error tracking (Sentry), accessibility regression checks, and a fixed allocation of editorial and engineering hours per month. For product teams without a dedicated React engineer in-house.

  • Dependency updates · weekly cadence
  • Core Web Vitals + bundle-size monitoring
  • Error tracking & alerting (Sentry)
  • Allocated hours: bug fixes, small features, refactors

DX, CI & design-system setup

The engineering foundations that compound over years: TypeScript config tuned to your team's maturity, Vitest + Playwright test infrastructure, GitHub Actions / CircleCI pipelines, Storybook for component development, design tokens shared between Figma and code, and Shadcn / Radix design-system implementation. Done once, reused across every project.

  • TypeScript config + path aliases + strict mode
  • Vitest + RTL + Playwright test stack
  • Storybook + design tokens + Shadcn / Radix
  • CI: lint, type-check, test, preview deployment
Framework & bundle scoreboard

The numbers every React build we ship has to hit.

Every React build is shipped against four hard targets. We measure, we tune, we re-measure. Below the line, the build is not done and the engagement is not closed until each number is in the green.

01 — Initial JavaScript bundle

Under 150 KB gzipped · route-split · every page

Main entry bundle under 150 KB gzipped on first load. Route-level code splitting so each subsequent route loads its own ~30-80 KB chunk on demand. Treeshaken libraries; no moment, no full lodash, no unused MUI components shipping.

MAIN 128 KB ROUTE 42 KB · lazy VENDOR 88 KB · cached TOTAL 258 KB Route-split · tree-shaken No moment / lodash bloat Vendor cached separately UNDER BUDGET · GREEN
02 — FCP, LCP, TTI

FCP under 0.9s · LCP under 1.5s · TTI under 2.2s

First Contentful Paint under 900 ms on mid-range mobile. LCP under 1.5 s on the largest content element. Time to Interactive under 2.2 s. Measured on real Chrome user data, not just on a developer machine.

FCP 0.8s LCP 1.2s TTI 1.9s 0s 2s
03 — Hydration & INP

Hydration under 200 ms · INP under 100 ms

App Router with Server Components keeps hydration cost minimal — only client components hydrate. INP under 100 ms means interactions feel instant. No hydration mismatches, no unnecessary re-renders, no main-thread blocking from third-party scripts.

HYDRATION 172 ms INP 68 ms CLS 0.02 RSC ships less JS Selective hydration Profiled render cycles PASSING · GREEN
04 — Accessibility (WCAG 2.2 AA)

WCAG 2.2 AA · Lighthouse a11y 100 · every build

Colour contrast checked per token. Full keyboard navigation. Screen-reader landmarks audited. Focus management on modals and route transitions. ARIA used correctly and minimally. Built on Radix, React Aria, or Shadcn primitives that get accessibility right by default.

Keyboard nav · every interactive element Radix / React Aria primitives · accessible by default Lighthouse accessibility 100 · every page
How we work

Five steps from brief to a React app your team can run for a decade.

The process below has stayed the same for ten years and 1,000+ React builds. Every step is required. Skipping any one of them is how React apps end up slow, fragile, or unmaintainable.

01

Brief and product spec

We learn the product, the team, the existing codebase (if any), the integrations, the performance and accessibility targets, and what success looks like at year three. We finish with a written brief, a product spec, and an architecture diagram on paper.

02

Architecture and engineering plan

Stack decisions (Next.js vs Vite, App Router vs Pages Router, state libraries, design system), data architecture, deployment target, performance budgets, test strategy, CI / CD pipeline. The architecture is decided before any visual or feature work starts.

03

Custom React build

TypeScript-first React build. Server Components where they help, client components where they are needed, design-system primitives (Radix, React Aria, Shadcn), Tailwind for styling. Weekly demos, two-week sprints, preview deploys on every PR.

04

Performance and accessibility testing

Real-device testing across Chrome, Safari, Firefox, mobile Chrome, mobile Safari. Core Web Vitals tuned on staging. Lighthouse mobile run on every PR. WCAG 2.2 AA audit. Bundle-size monitoring against budget. The team that will run the app uses it before launch.

05

Launch, monitor, maintain

Launch checklist, sentry / error tracking live, Core Web Vitals monitoring in production, analytics confirmed firing. Monthly maintenance from day one. Quarterly architecture and performance reviews.

Selected work

React apps we have shipped across SaaS, internal tools, real-time collab, marketing, and headless commerce.

Six React apps from the last 24 months. Every one passes Core Web Vitals, hits WCAG 2.2 AA, runs under a 150 KB initial JavaScript budget, and a mid-level engineer can pick it up on day one.

Meridian Analytics
LCP 0.9s · AA · 98 Lighthouse
SaaS analytics · Next.js App Router
Stratos Workspace
LCP 1.1s · AA · 96 Lighthouse
B2B SaaS · Vite + React
Aurora Editor
LCP 1.0s · AA · 97 Lighthouse
Real-time collab · Custom React
Postbrew
LCP 0.7s · AA · 99 Lighthouse
Marketing site · Next.js / Astro
Frondhill OS
LCP 1.2s · AA · 95 Lighthouse
Internal tools · Vite + React
Chayya Headless
LCP 0.8s · AA · 98 Lighthouse
Headless commerce · Hydrogen

Need a React app that actually performs?

Send us a one-paragraph brief about the product, the team, and where you want to be in three years. We will come back with a free, honest plan — fixed scope, fixed targets, no slides.

Request a discovery call
Where it shows up

Four kinds of React build, one engineering team behind them.

The same React + Next.js capability adapts to four very different surfaces. Visual language stays consistent; what changes is the architecture, the data model, the deployment target, and the rhythm the team will run the app on.

SaaS dashboards

Product UI & dashboards

Logged-in product applications with complex tables, charts, real-time updates, multi-step workflows. Vite + React + TypeScript + a design system. Built so engineers can ship features fast and the product stays stable.

Marketing sites

SaaS marketing & content

Marketing sites where SEO and Core Web Vitals are competitive axes. Next.js App Router with Server Components, or Astro for content-heavy sites with minimal interactivity. Sub-1s LCP on every page.

Headless commerce

Headless storefronts

Hydrogen + Oxygen storefronts on Shopify, Sanity-driven content sites, Contentful-driven brand sites, custom GraphQL backends. React storefronts with sub-second LCP and a content model the merchandising team can extend.

Internal tools

Internal tools & admin UI

Custom admin interfaces, internal tools, ops dashboards, agent-facing applications. Vite + React + a focused design system. Optimised for engineer productivity rather than first-load performance.

Client stories

Two React engagements, and what changed for the businesses behind them.

Meridian Analytics

B2B SaaS analytics · UK + US · 2024–2025
The situation

A Series-B analytics SaaS on Create React App with a 780 KB initial bundle, 4.1-second mobile LCP on the marketing site, and a product app that mid-level engineers struggled to onboard onto. Sign-up conversion had plateaued; engineering velocity had slowed; the team knew the architecture was the problem but did not have bandwidth to fix it.

What we did

Migrated the marketing site to Next.js App Router with Server Components (4 weeks). Migrated the product app from CRA to Vite (3 weeks). Cut the initial bundle from 780 KB to 142 KB through route-level code splitting and dependency rationalisation. Replaced legacy Redux + Saga with TanStack Query + Zustand. Built a Shadcn-based design system. Set up Vitest + Playwright + GitHub Actions CI.

The outcome

Marketing site LCP moved from 4.1s to 0.9s. Sign-up conversion was up 31% within the first 90 days. Product app first-load improved 65%. Engineering velocity (measured in story points per sprint) increased 40% over the next two quarters. A mid-level engineer can now onboard and ship in week one.

More about Meridian Analytics →

Aurora Editor

Real-time collaboration · Custom React · 2023–2026
The situation

A pre-launch document-collaboration product where the UI itself is the product. Real-time multi-user editing, presence awareness, comments, suggestion mode, version history. The founding team had a working prototype that did not scale past five concurrent users and that no one but the original engineer could maintain.

What we did

Rebuilt the React app on Vite + TypeScript + TanStack Query + Yjs (for CRDT-based real-time sync) + Tiptap (for the editor primitive). Architected around React Aria for accessibility and a custom design system. Built a comprehensive test suite including Playwright multi-tab tests for real-time scenarios. Deployed on Cloudflare with edge functions for WebSocket termination.

The outcome

Scales to 200 concurrent users per document with sub-50 ms edit latency. WCAG 2.2 AA across every interaction (rare for editors). Three new engineers onboarded in the first two months and shipped to production by week three. The original prototype engineer is now a force-multiplier lead engineer rather than a sole-engineer with bus-factor-of-one.

More about Aurora →
For agencies & product teams

The React engineering team behind the agency.

Roughly 35% of our React work is built for other agencies, product studios, and consultancies — under their brand, against their clients' deadlines. Three partnership models, all NDA-protected, with senior React engineers working in time zones overlapping the UK, EU, and US workday.

01 · Partnership model

White-label React development

Your brand. Our engineers. We never appear in front of your client — all communication, deliverables, and code go out under your name. The standard model for agencies that win React projects but do not want to hire in-house React engineering.

  • NDA & sub-contract in place before any work begins
  • Code, design files, and deliverables shipped under your brand
  • Joint Slack / email channels with your team only
  • You stay client-facing; we stay implementation-facing
Used by: digital agencies, brand studios, product consultancies
02 · Partnership model

Agency-of-record & dedicated React pod

A pod of senior React engineers, a front-end developer, and a project lead working as your in-house React capacity — full-time or fractional, month-to-month or annual. The choice when React is core to your service mix and hiring in-house is slower or more expensive than partnering.

  • Dedicated pod: 2 to 6 engineers + lead, scaled to your roadmap
  • Direct integration into your project tools (Jira, Linear, ClickUp, Asana)
  • Monthly capacity commitment; retainer or rolling SoW
  • Code ownership transferred to your repos
Used by: full-service agencies, SaaS product teams
03 · Partnership model

Capacity overflow & sprint-by-sprint

When your in-house React team is full and the next project cannot wait. Sprint-by-sprint engagement, no commitment beyond the current two-week sprint, ready to pick up scoped work within 5 to 7 business days from green-light.

  • Two-week minimum sprint, rolling renewal
  • Scoped fixed-price work — feature build, migration, performance pass
  • Fast spin-up: 5 to 7 business days from signed SoW
  • No long-term commitment; ramp up or down per sprint
Used by: agencies with seasonal React demand spikes
NDA-protectedStandard NDA, sub-contract, and IP transfer in place before any work begins.
Time-zone overlapWorking hours overlap with UK mornings, EU workday, and US afternoons every business day.
Single point of contactNamed project lead on every engagement. No agency-side account churn.
Your repos, your codeCode ownership transfers cleanly. We work in your Git, your hosting, your tooling.
Already running an agency or product team? Explore our white-label terms Start a partner conversation
Why not

Cheap React shops, low-code platforms, and over-engineered solo builds vs React done properly.

Three routes most product teams consider before they hire a React engineering team. Each makes sense for someone. None hold up to scale the way a properly architected custom React build does.

Cheap React shop
  • CRA + 40 npm dependencies + no TypeScript
  • 600+ KB initial bundle · fails Core Web Vitals
  • No design system · every component reinvented
  • Breaks on the next major React or Next.js version
  • Cheap up-front · expensive to rebuild in 12-18 months
Low-code / Webflow / Bubble
  • Drag-and-drop with limited backend logic
  • Hits a ceiling on custom functionality & integrations
  • Hosted · you cannot export or move
  • Performance ceiling: typically LCP 2.5-3.5s
  • Right for early MVPs · outgrown by year two
Custom React at Dream Steps
  • TypeScript-first · design system · tested
  • Sub-1.5s LCP · WCAG 2.2 AA · 95+ Lighthouse
  • Initial JS under 150 KB · route-split · treeshaken
  • Architected so mid-level engineers can ship
  • Higher year one · dramatically lower years two and three

Cheap React is the most expensive React.

The savings show up in month one. The cost shows up in the rebuild, the lost conversion, the slow engineering velocity, and the team you cannot hire because the codebase scares senior candidates away. Every cheap React build we have inherited has cost the client more in rebuild than custom would have cost first time round.

Low-code platforms work for the brief they were built for.

Marketing sites that will not change much. Internal MVPs. Prototypes. The moment the business needs real functionality, real integrations, or scale, you are either rebuilding or working around the platform. The work-around is rarely cheaper than the rebuild, and the rebuild is rarely cheaper than starting with custom React from day one.

A custom React build does more, lasts longer, and the team can ship on it.

It costs more up front because that is what it costs to architect a codebase around the product, the team, and the three-year roadmap rather than fit the business around someone else's template. Three years in, the maths favours it on almost every axis we measure — engineering velocity, performance, hire-ability, total cost of ownership.

— The honest read

Build the React app that fits the team in three years.

Request a React engagement
Common questions

Questions React buyers actually ask.

Fourteen of the most common WordPress questions, answered straight. If yours is not below, send it and we will reply with a real answer — not a sales pitch.

Why choose Dream Steps for React and Next.js development?

We have shipped 1,000+ React apps since 2015 across Next.js (App Router and Pages Router), vanilla React with Vite, Remix, and Astro. Our 40-person team of senior React engineers, designers, and project leads in Noida, India works in time zones overlapping the UK, EU, and US workday. We hold every build to four hard targets: sub-1.5-second LCP, WCAG 2.2 AA, 95+ Lighthouse mobile, and initial JavaScript under 150 KB gzipped. We do not white-label other agencies’ work and tell clients honestly when React is not the right answer.

Can you white-label React / Next.js development for our agency?

Yes — roughly 35% of our React work is built for other agencies, product studios, and consultancies under NDA. Three partnership models: white-label (your brand, our engineers, fully invisible), agency-of-record (a dedicated React pod working as your in-house capacity), and capacity overflow (sprint-by-sprint engagement when your in-house team is full). Code ownership transfers to your repos. Time zones overlap with the UK, EU, and US workday.

Where is your React team based?

Our entire React engineering team is based in Noida, India — 40 people in our iThum Tower B office, founded in 2015. We work with product teams and agencies across the UK, US, Ireland, Australia, the UAE, Germany, and the Netherlands. Working hours overlap with UK mornings (your 9 AM to noon), the full EU workday, and US afternoons (your 1 PM to 6 PM EST). For agency partners we run in their tooling — Slack, Jira, Linear, ClickUp, Asana — as standard.

Should I use Next.js or vanilla React (Vite)?

Next.js for anything customers find through Google (marketing sites, content engines, e-commerce, product pages) — SSR and Server Components are not optional when SEO matters. Vanilla React with Vite for logged-in product applications (SaaS dashboards, internal tools, real-time interfaces) where the UI is the product and SEO does not matter. Most applications need one or the other, not both; picking the wrong stack is the most expensive React architecture mistake we see.

How much does a custom React or Next.js build cost?

Custom React builds range from small marketing sites through to enterprise SaaS applications and headless commerce frontends. The right scope drivers are application complexity, custom functionality, integrations, performance targets, and the team’s React maturity. We scope every engagement against the specific brief and are honest about which features can wait until phase two.

How long does a custom React or Next.js build take?

A typical custom Next.js marketing site takes 6 to 10 weeks. A SaaS dashboard or product application takes 10 to 16 weeks depending on feature scope. A headless commerce frontend with Shopify or another headless CMS takes 8 to 14 weeks. Migrations (CRA to Vite, Pages Router to App Router) typically add 4 to 12 weeks depending on app size. We work in two-week sprints with weekly demos throughout.

Will my React app be fast?

Yes — every React build we ship hits sub-1.5-second LCP, sub-0.05 CLS, INP under 100 ms, and a Lighthouse mobile score above 90. We achieve this through proper code splitting, Server Components where appropriate, AVIF / WebP images with responsive srcset, deferred third-party scripts, profiled render performance, and initial JavaScript bundles under 150 KB gzipped. Performance is part of the build, not an afterthought.

Do you build with App Router or Pages Router?

For new Next.js builds in 2026, App Router is our default — smaller client bundles via Server Components, cleaner data fetching, streaming, and Server Actions. For existing Pages Router apps that work well, we maintain them on Pages Router and migrate only when there is a specific reason (planned features that benefit from RSC, performance walls, or rebuilds happening anyway). We will tell you honestly which router fits your project.

Can you build accessible React apps (WCAG 2.2 AA)?

Yes. WCAG 2.2 AA is our baseline on every React build — colour contrast checked per token, full keyboard navigation tested, screen-reader landmarks audited, focus management on modals and dialogs, ARIA used correctly and minimally. We use Radix, React Aria, and Shadcn UI as primitives that get accessibility right by default. Accessibility is part of the build, not a fix after launch.

Can you handle headless commerce frontends (Shopify Hydrogen, Sanity, Contentful)?

Yes. We have built headless storefronts with Shopify Hydrogen + Oxygen, Sanity-driven content sites, Contentful-driven marketing sites, and custom GraphQL backends with Next.js. Headless commerce is one of our specialities — see our Shopify Development page for the deeper take on Hydrogen vs standard Shopify, and our content cluster on App Router vs Pages Router for the Next.js-specific architecture choices.

Will you maintain the React app after launch?

Yes. We offer monthly React maintenance retainers covering dependency updates (React, Next.js, third-party libraries), security patches, Core Web Vitals monitoring, accessibility regression checks, bundle-size monitoring, error monitoring (Sentry or equivalent), and a fixed allocation of editorial and development hours. For product teams without a dedicated React engineer in-house, this is how the app stays healthy past month one.

Can you migrate my existing React app to Next.js (or to Vite)?

Yes. CRA to Vite migrations are typically 1 to 3 weeks and yield 20 to 40% performance improvement before any other work. Pages Router to App Router migrations are 4 to 12 weeks depending on app size and complexity. Vanilla React to Next.js migrations are 6 to 16 weeks — effectively a rebuild of the routing and data-fetching layers while preserving component code. We have done each many times; we will tell you on the discovery call whether migration is the right call or whether optimising what you have makes more sense.

Can you take over a React project that's already in flight?

Yes. We routinely inherit React projects mid-build — codebases left by a previous agency, internal projects that stalled, MVPs from the founder’s first engineer that need to be scaled up. We start with a code audit (architecture, performance, accessibility, dependency health, test coverage), present a written report with a salvage-vs-rewrite recommendation, then either improve or rebuild based on what serves the business. Most inherited projects are salvageable.

What stack do you ship for a typical SaaS dashboard?

Our default 2026 SaaS stack: React 18+ with TypeScript, Vite (or Next.js if SSR is wanted for marketing surfaces), TanStack Router or React Router, TanStack Query for server state, Zustand or Jotai for client state, Radix UI or Shadcn for accessible primitives, Tailwind for styling, Vitest + React Testing Library + Playwright for testing, deployed to Vercel, Cloudflare Pages, or AWS depending on infrastructure preference. We adjust based on the team and the requirements but the stack above is what we recommend by default.

Ready when you are

Build a React app your team can ship on for a decade.

Tell us about the product, the team, the integrations, and where you want to be at year three. We will come back with a written brief, a realistic build cost, and a clear set of performance, accessibility, and architecture targets we will hold ourselves to.

What to expect

A 30-minute conversation about your business, the editorial team that will run the site, and where you want to be in three years. No slide deck, no pitch.

You walk away with

A written brief naming the build scope, the performance and accessibility targets we will hold to, the timeline, and a realistic build cost.