Devesh Tiwari
← Back to insights
Web

Web Products That Scale Without a Rewrite

Devesh Tiwari12 min read

Architecture patterns for React and Next.js that survive real traffic, real teams, and the feature requests that follow launch.

Web Products That Scale Without a Rewrite

01

What architecture survives real growth?

Modular domains with explicit API boundaries, typed contracts, and observability hooks from the first production deploy.

Monoliths are fine until boundaries blur. I structure React/Next apps so new features land in isolated modules with shared design tokens and testable services. A `features/` or domain-based folder structure beats a flat `components/` dump once you have more than one engineer touching the codebase.

02

How should you split frontend and backend concerns?

Server components and route handlers for data fetching; client components only where interactivity demands it — with shared types between API and UI.

In Next.js App Router, default to server rendering for dashboards and marketing pages. Push client boundaries down the tree. On the API side, version endpoints when mobile clients depend on them. Document breaking changes. Teams that skip typed contracts spend their second year fixing silent integration bugs.

03

When should you invest in performance?

Before marketing spend — measure LCP, API p95, and error rates when traffic is still small so fixes are cheap.

Caching, image strategy, and database indexes are product decisions. Slow dashboards kill B2B trust as fast as consumer churn. Add performance budgets in CI: bundle size limits, Lighthouse thresholds on critical routes. Fixing a 4s page load at 100 users is a afternoon; at 10,000 users it is a quarter.

04

What database and API patterns avoid rewrites?

Normalize what must stay consistent; denormalize read paths that users hit constantly — with migrations treated as first-class releases.

Avoid N+1 queries in list views. Use pagination and cursor-based APIs from day one. Background jobs for email, exports, and webhooks — never block the request thread. I set up migration workflows and staging data early so schema changes do not become scary Friday deploys.

05

How do you onboard the second engineer without chaos?

Shared conventions: lint rules, PR templates, feature flags, and a written architecture note that fits on one page.

Scaling teams fail when every developer invents a new pattern. Establish how you name things, where tests live, and how features get toggled off in production. A senior product engineer documents this as they build — not as a post-launch cleanup task.

Frequently asked questions

Is Next.js required for a scalable web product?
No — but SSR/SSG in Next.js helps SEO and time-to-first-byte. Vite SPAs can scale with prerendering and a solid API layer. Choose based on your distribution model: SEO-heavy products benefit from Next; authenticated B2B tools may prioritize SPA speed after login.
When should I split into microservices?
When a specific domain has independent scaling needs, deployment cadence, or team ownership — not because the monolith feels large. Most startups rewrite too early and pay in operational overhead.
How do I handle auth at scale?
Use a proven provider (Clerk, Auth0, Supabase Auth) or battle-tested session patterns. Roll your own only when requirements are truly unique. Session security, password resets, and OAuth edge cases are not where you differentiate.
What should I monitor from launch day?
Error tracking (Sentry or similar), API latency percentiles, uptime on critical paths, and database slow-query logs. Add business events alongside technical metrics so you can connect outages to revenue impact.