An honest look at why Next.js is our default framework for web applications — what it does well, where it falls short, and the specific situations where we'd recommend something else.
What is Next.js? Next.js is a React framework that adds server-side rendering, file-based routing, API routes, and deployment optimization on top of React. It lets developers build full-stack web applications with a single framework instead of stitching together separate tools for the frontend, backend, and routing.
We've shipped 50+ production applications with Next.js. It's our default choice for web applications, SaaS platforms, e-commerce storefronts, and marketing sites. But it's not always the right choice.
This guide explains our reasoning — not as a sales pitch for Next.js, but as a transparent look at how we make technology decisions and why framework choice matters less than most developers think.
Before Next.js, building a web application required separate decisions for:
Next.js handles all of this. One framework, one build system, one deployment. This isn't just convenient — it eliminates an entire category of integration bugs and configuration drift.
For our clients, this means faster development, lower maintenance costs, and fewer things that can go wrong.
React Server Components (RSC), which Next.js adopted early through its App Router, fundamentally changed how we build applications.
Before RSC: Every component shipped JavaScript to the browser. A product listing page with 50 products meant the browser had to download, parse, and execute the code for rendering all of them — even though the data came from the server anyway.
With RSC: Server Components render on the server and send pure HTML to the browser. Only interactive components (add-to-cart buttons, filters, modals) ship JavaScript. The result is dramatically faster initial loads, better SEO, and lower data transfer.
For a typical e-commerce page, this means 60-70% less JavaScript sent to the browser compared to a traditional React SPA.
Next.js supports multiple rendering strategies in the same application:
Most frameworks force you to pick one strategy for the entire app. Next.js lets you pick per-page or even per-component. This means the marketing homepage loads in under 1 second (static), the product page shows accurate inventory (ISR), and the dashboard streams real-time data (SSR).
We write everything in TypeScript. Next.js has excellent TypeScript support — from typed route parameters to typed server actions to typed API routes. The type safety extends from the database query all the way to the rendered component.
This catches entire categories of bugs at compile time. When we change a database column name, TypeScript tells us every file that needs updating — before the code ever runs.
Next.js deploys to Vercel with zero configuration. Push to GitHub, deployed in 90 seconds. Preview deployments for every pull request. Edge functions for global performance.
But we're not locked in. Next.js also deploys to AWS, Docker, Cloudflare, and any Node.js hosting. When clients need self-hosted infrastructure for compliance or data residency requirements, we deploy there without rewriting anything.
Need authentication? Clerk, NextAuth, or Auth0 all have first-class Next.js integrations. Payments? Stripe's SDK works seamlessly with server actions. CMS? Every headless CMS has a Next.js starter. Database? Prisma, Drizzle, and every major ORM supports the Next.js model.
This matters because we spend our time building your product's unique value, not reinventing solved problems.
We're not blind enthusiasts. Next.js has real limitations.
Sites with 50,000+ static pages can have long build times. ISR and on-demand revalidation help, but if you're generating hundreds of thousands of pages, Next.js builds can take 20+ minutes. For these cases, we sometimes split the static generation across multiple builds or use on-demand generation exclusively.
The App Router is powerful but has a learning curve. Server Components, client components, server actions, and streaming SSR all have specific rules about what can be used where. For developers new to the framework, this complexity can slow down initial development.
We've internalized these patterns across 50+ projects, so it's not an issue for us. But if you're hiring in-house developers to maintain a Next.js app, factor in the learning curve.
Next.js is developed by Vercel. While it's open-source and self-hostable, some advanced features (like certain caching optimizations) work best on Vercel's platform. We're transparent about this — and we make sure every project we build works perfectly on any hosting platform.
A marketing site with 5 pages and a contact form doesn't need server components, streaming SSR, or middleware. We'll build it with Next.js because it's what we're fastest with, but a simpler tool (Astro, plain HTML) would work just as well.
For native mobile apps, we use React Native or recommend Flutter. Next.js can power the API and web version, but the mobile app itself needs a mobile framework.
For applications where real-time is the primary feature (multiplayer games, live collaboration editors, chat-first applications), we might use a more specialized stack. Next.js can handle real-time features, but if 90% of the app is WebSocket-driven, frameworks like Elixir/Phoenix or dedicated WebSocket servers might be more appropriate.
For pure documentation sites with thousands of pages of static content, Astro or similar static-first frameworks can be simpler and faster. Next.js works for docs, but it's more framework than the job requires.
If you have a Rails, Django, or Laravel backend that works well and you just need a better frontend, we might build a standalone React SPA or use the existing framework's frontend capabilities. Replacing a working backend with Next.js just because we prefer it would be irresponsible.
Framework choice is a business decision, not a religious one. Here's our actual decision process:
Does the team have expertise? We're fastest with Next.js. Building with an unfamiliar framework means slower delivery and more bugs. Our expertise is your cost advantage.
Does the client need to maintain it? If the client's team uses Python/Django, we might recommend building the frontend in Next.js with a Django API — so they can maintain the backend themselves.
What are the deployment requirements? Government contracts might require on-premise deployment. Next.js self-hosts fine, but if the requirement is "no JavaScript frameworks," we adapt.
What's the expected lifespan? For a quick validation experiment, we use whatever ships fastest. For a 5-year platform, we choose for maintainability and hiring.
What are the performance requirements? For most web applications, Next.js exceeds performance needs. For extreme cases (millions of requests per second, sub-10ms latency), we might need a different architecture.
Next.js is our default because it's the best general-purpose framework for production web applications in 2026. It handles 95% of what our clients need, we're extremely fast with it, and it results in applications that are fast, maintainable, and scalable.
But "default" doesn't mean "always." We evaluate every project individually and recommend what's best for the specific situation — even when that's not what we prefer.
The framework matters less than most people think. A well-architected application built with the "wrong" framework will outperform a poorly-built application on the "perfect" framework every time. We focus on architecture, code quality, and shipping speed. Next.js just happens to make all three easier.
Building a web application and wondering about the right tech stack? Book a free discovery call — we'll give you an honest recommendation based on your specific requirements. See our Next.js development services or explore how much web apps cost.
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
A transparent breakdown of real web app development costs — from simple MVPs to complex platforms. Includes pricing factors, common traps, and how fixed-price models actually work.
12 min readBuilding ProductsThe real process of turning a product idea into working software — from napkin sketch to production launch. Written for non-technical founders who want to understand what happens and when.
14 min read