job 01 · server components
Data + structure, zero JS.
Render on the server, stream HTML to the client, fetch data inline. Default for content, layouts, and anything read-only. The single biggest bundle-size win since tree-shaking.
§
§ · react development
React development, past hydration.
A Server-Components-first React practice. For SaaS products, content platforms, and client portals built on Next.js 16 App Router, Suspense streaming, and the server-client boundary that modern React expects.
On this page
§ 01 · react has three jobs now
Every component is doing one of three jobs.
Modern React is no longer one thing. In 2026, every component is one of three shapes: Server Component, Client Component, or Server Action.
Knowing which shape each component is doing is the central architectural discipline. Codebases that treat every component the same way end up with hydration taxes they cannot afford and bundle sizes they cannot explain.
in short
- Default to Next.js 16 App Router; Remix for nested-routing-heavy platforms; Vite SPA only for pure dashboards.
- Server Components for read-only content, Client Components as small islands, Server Actions for type-safe mutations.
- State stack: useState + useContext → Zustand → TanStack Query (client data) + React Hook Form + Zod (forms). No Redux in new builds.
- Strict TypeScript day one (
strict: true, noany). Three test layers: Vitest + React Testing Library + Playwright. - Four engagement shapes: 2-week audit (refundable), new build, SPA migration, retainer. Code + infra ownership transfers to client.
job 02 · client components
Interactivity, costs JS.
Marked with use client. Hydrate in the browser; handle state, effects, events. The surface area of client components is your bundle size.
job 03 · server actions
Mutations, type-safe.
Async functions marked use server. Run on server, called from client. Replace REST mutation endpoints. Type-safe end-to-end, no manual API layer.
§ 02 · framework decision
Next.js, Remix, or Vite SPA. Pick by shape, not by brand.
Three React frameworks cover almost every modern project. Next.js 16 App Router is our default because it is where React Server Components live as a first-class concept.
Remix wins when you need framework-agnostic routing and nested error boundaries. Vite SPA is only for pure client-side dashboards: no SEO, no initial-load performance needs, and no server-side rendering.
| Vite SPA | Next.js 16 App Router | Remix | |
|---|---|---|---|
| rendering | client only | RSC + SSR + ISR + static | SSR + streaming + optional RSC |
| data fetching | client-side via useEffect / SWR / TanStack | Server Components fetch inline | loaders (server-side) + actions |
| bundle size | largest (all code ships) | smallest (RSC ships zero JS) | smaller than SPA, larger than RSC |
| SEO + CWV | weak; hydration tax | best available for React | strong |
| best for | internal dashboards, auth-gated | 80% of modern builds | form-heavy platforms, nested routing |
§ 03 · the server-client boundary, in motion
One tree. Two runtimes.
The hardest thing about modern React is knowing where the server stops and the client begins.
The animation below draws this boundary on a typical component tree. Everything above the amber line renders on the server and streams as HTML. Everything below hydrates on the client.
§ 04 · rsc + suspense patterns
Four patterns cover most modern React.
pattern 01 · server-first data
Fetch in the component.
Server components fetch data directly inline. No useEffect. No loading state passed through props. No SWR wrapper. Data fetching lives in the component that renders it.
pattern 02 · client islands
Small, interactive.
Client components are islands inside server pages: the comment input, the cart button, the modal trigger. The rest stays server-side. Bundle stays small.
pattern 03 · suspense streaming
Parallel fetches, progressive render.
Wrap slow parts of the page in Suspense. Fast parts render first, slow parts stream in as data arrives. Users see meaningful content in hundreds of milliseconds, not seconds.
pattern 04 · server actions
Typed mutations.
Forms, updates, deletes via Server Actions. No REST endpoint. No tRPC router. Type-safe from form submit to database. The write path most React apps have been missing.
§ 05 · state management
Most state is not client state anymore.
RSC plus Server Actions eliminate most of what client state was used for.
Remote data, form submission state, and cache invalidation all move server-side. What remains is genuinely client-only: UI state, derived values, and cross-component ephemeral state. The matrix below shows what we reach for on new builds.
| what you need | what we reach for | why |
|---|---|---|
| simple UI state | useState | no library, no overhead |
| shared UI state in a subtree | useContext | colocated, explicit |
| cross-component client store | Zustand | small, typed, no boilerplate |
| atomic fine-grained reactivity | Jotai | when component re-renders must be surgical |
| remote data (client-fetched only) | TanStack Query | cache, refetch, invalidate done right |
| form state | React Hook Form + Zod | validated, typed, performant |
§ 06 · typescript + testing
Strict typing and three test layers. No exceptions.
TypeScript strict on day one and a three-layer test pyramid (unit, component, E2E) keep the bundle clean and regression surface small as the codebase scales past 50K lines.
typescript discipline
- ✓strict: true on day one; noUncheckedIndexedAccess on day two
- ✓No any; no unknown cast without runtime validation
- ✓Zod on every API boundary; generated types from DB schema
- ✓Branded types for IDs and sensitive primitives
testing layers
- ✓Vitest for unit tests on pure logic, 90%+ on critical utils
- ✓React Testing Library for component behavior, user-visible only
- ✓Playwright for E2E on critical journeys (signup, primary conversion)
- ✓MSW for HTTP mocking; CI runs on PRs, deploy blocked on red
§ 07 · performance SLA
The numbers we hold ourselves to on Next.js 16.
We set per-template Core Web Vitals targets and bundle-size budgets, then verify against web.dev/vitals field data at every release.
Lab scores in CI are not enough. We test on real mid-tier mobile hardware to catch performance regressions early.
| template | LCP | INP | CLS | JS bundle (gzip) |
|---|---|---|---|---|
| marketing page | < 1.6s | < 150ms | < 0.05 | < 40 KB |
| content / article | < 1.8s | < 150ms | < 0.05 | < 60 KB |
| authenticated dashboard | < 2.2s | < 180ms | < 0.08 | < 140 KB |
| form / checkout | < 2.0s | < 180ms | < 0.08 | < 100 KB |
Two archetypes. One built, one migrated.
Two industry archetypes from real SaaS and content-platform engagements. One is a Next.js 16 build from scratch. The other is a Pages Router to App Router migration with zero traffic drop.
archetype 01 · SaaS product, $2M ARR
Next.js 16 from scratch.
Vertical SaaS with authenticated dashboard, public marketing, Stripe billing. Server Components throughout, client islands for editor and chart interactivity. Ship to Vercel edge, Postgres on Neon. 14 weeks.
LCP marketing
1.2s
mobile p90
JS bundle
38 KB
marketing pages
test cov
78%
critical paths 94%
archetype 02 · content platform, 4M pageviews/mo
Pages Router → App Router migration.
Large content platform on Next.js 12 Pages Router. Migrated route by route to App Router with Server Components. 18-week migration, no traffic drop during transition. 62 percent bundle size reduction on content pages.
bundle cut
-62%
content pages
LCP win
-1.1s
mobile p75
traffic
stable
zero drop
§ 09 · engagement shapes + fit
Four shapes. Audit names the right one.
shape 01
Architecture audit.
2 weeks. Boundary + bundle + state review. Refundable. Contact for quote.
shape 02
New build.
10-18 weeks. Next.js 16 from scratch. Contact for quote.
shape 03
SPA migration.
12-20 weeks. SPA / Pages Router → App Router. Contact for quote.
shape 04
Retainer.
20+ hrs/week named engineers. Month to month. Contact for quote.
right fit
- ●SaaS, content platform, or client portal on React
- ●You want Server Components and App Router as the default
- ●TypeScript strict-mode and 70%+ test coverage are non-negotiable
- ●You can own the codebase after we hand off
wrong fit
Eight answers.
The questions React teams ask most often before booking an architecture audit. When to use Vite SPA. RSC versus SSR. Migration scope. State management. TypeScript strictness. Testing. Exit ownership.
Should we still use Create React App or Vite SPA in 2026?
No for new projects. CRA has been deprecated since 2023. Vite SPA is a good development tool but the wrong production default.
For a new React project in 2026, start with Next.js 16 App Router or Remix if you need framework-agnostic routing. Vite + React Router is acceptable only for pure interactive dashboards with no SEO, no initial-load performance needs, and no server-side rendering. In practice, that covers under 15 percent of projects.
What's the difference between Server Components and SSR?
SSR (Server-Side Rendering) renders the full React tree on the server, ships HTML plus the full JavaScript bundle, and hydrates everything on the client.
Server Components render on the server and ship zero JavaScript for those parts. Only Client Components ship JS. The result is dramatically smaller bundles, faster Time to Interactive, and a natural way to fetch data close to where it's rendered.
SSR was about when to render. Server Components are about what to ship.
How much does custom React development cost in 2026?
US and UK senior React engineers cost $150-210 per hour at boutique agencies. Indian mid-market senior engineers cost $95-150 per hour.
A Next.js 16 App Router build runs 10-18 weeks. A migration from SPA or Pages Router to App Router runs 12-20 weeks. A 2-week architecture audit is refundable against any future engagement. Retainer engagements start at 20 hours per week of named engineer time.
Get a scoped quote in 48 hours.
Do we need to rewrite everything to use Server Components?
No. A full codebase rewrite is the wrong default.
Next.js App Router allows incremental adoption: new routes on App Router, legacy routes on Pages Router side by side. We migrate route by route, starting with highest-traffic content pages for the biggest bundle-size wins. Interactive dashboards stay on the existing router until the migration naturally reaches them.
Plan for 4-8 months of incremental migration with per-route testing.
Which state management library do you recommend?
By default, none. React Server Components plus Server Actions eliminate most of what client state was used for: remote data, form state, cache invalidation.
What remains is genuinely client-only: UI state (modals, drawers, tabs), derived values, and cross-component ephemeral state. useState and useContext are the right default for that.
If you need more, use Zustand for small stores, Jotai for atomic fine-grained reactivity, or TanStack Query for client-side data fetching. We avoid Redux in new builds because its conceptual weight does not match modern React.
How do you handle TypeScript strictness?
strict true on day one. noUncheckedIndexedAccess true on day two. exactOptionalPropertyTypes true when the codebase can absorb it. No any. No unknown cast without runtime validation.
Zod or Valibot on every API boundary. We generate TypeScript types from the database schema (Prisma, Drizzle, or Kysely) and from tRPC or Server Actions so the frontend always knows what the backend returns.
Strict TypeScript on React pays back its setup cost in the first month of maintenance.
What's your testing approach for React?
Three layers. Vitest for unit tests on pure functions, utility modules, and component logic. React Testing Library for component behavior tests, focused on what the user sees and interacts with, not implementation details. Playwright for end-to-end tests on critical user journeys (signup, checkout, primary conversion flows). MSW for mocking HTTP at the service-worker level so tests are isolated. Coverage target is 70 percent overall, 90 percent on critical paths. We do not chase 100 percent coverage; it is an anti-pattern.
Who owns the code, hosting, and deployment on exit?
You do. Private GitHub repository under your organization from day one. Deployment on your Vercel, Netlify, Cloudflare Pages, or AWS account. Domain on your registrar. Third-party services (Sentry, Clerk, Stripe) under your billing. DH engineers get named access, removable any time. On exit we transfer the repository, document the deployment pipeline, record a Loom walkthrough of the architecture, and leave a 30-day support tail. No lock-in through code, config, or vendor choice.
Start with an architecture audit.
Two weeks. Boundary review, bundle analysis, state management, upgrade path. Refundable against any engagement that follows. Scoped quote in 48 hours.
related services
Published · Last updated .
