Architecting for Scale: Why We Bet on Next.js

## Why We're All-In on Next.js for Production Web Apps When a client asks us what framework to use for their new web platform, the answer has been Next.js for the past two years without hesitation. Here's the full reasoning — including the tradeoffs we've wrestled with. ## The Problem with Traditional SPAs React SPAs were revolutionary in 2016. By 2023, they had a well-documented set of production problems: - **Slow Time to First Contentful Paint (FCP)**: JavaScript bundle ships to browser, executes, fetches data, renders. Three round trips before the user sees anything. - **SEO dependence on crawlers**: Most bots still struggle with client-rendered content. - **Bundle bloat**: Every npm install ships to every user. - **Waterfall data fetching**: Child components can't fetch until parent renders. Next.js App Router — specifically the RSC (React Server Components) model — solves all four. ## Server Components: The Architecture Shift With RSCs, components that don't need interactivity run entirely on the server. They: - Have zero JavaScript bundle footprint on the client - Can directly query databases, call APIs, read files - Stream HTML to the browser progressively The mental model shift is significant. You're no longer thinking "fetch data in useEffect and render it." You're thinking "this component runs on the server and returns HTML." For a typical marketing page with heavy data requirements (portfolio items, blog posts, service details), we've seen FCP drop by 40-60% after migrating from a SPA architecture to RSC-first Next.js. ## Edge Runtime: Getting Closer to the User Vercel's edge network runs Next.js middleware and edge API routes in data centers around the world — milliseconds from the user instead of seconds. For the NirmataAI site itself, static pages are pre-rendered at build time and served from CDN edge nodes. Dynamic routes (like the contact form API) run on edge functions. The result: sub-100ms response times globally. ## When NOT to Use Next.js In the spirit of honesty: Next.js is not always the right tool. - **Highly interactive apps** (e.g., Figma, complex dashboards): The server-first mental model fights against the grain of apps that are 90% client state. React without RSC, or a framework like SvelteKit, may be better. - **Small sites with no dynamic data**: A static site generator (Astro, Hugo) will be simpler and cheaper. - **Mobile apps**: Obviously. Use React Native, Flutter, or native. ## Our Stack Recommendation for 2026 For product companies and agencies building modern web platforms: | Layer | Our Choice | Why | |-------|-----------|-----| | Framework | Next.js 15 | RSC, App Router, edge support | | Styling | Tailwind CSS v4 | CSS-first config, no config files | | Database | Postgres (via Supabase or Neon) | Reliability, familiarity, SQL | | Auth | Supabase Auth | Managed, integrates with DB | | Deployment | Vercel | Zero-config, edge, analytics | | State | Zustand + React Query | Simple global state + server sync | This stack is predictable, well-documented, and fast to hire for. Those properties matter more than any individual technical advantage. ## The Takeaway The next generation of web apps will be built server-first by default. Client JavaScript will be the exception, not the rule. Next.js is currently the best implementation of that vision in production. If you're starting a new web project in 2026 and you're not starting with this conversation, you're leaving performance and developer experience on the table.

nirmataAI team

Author