React Beyond Next.js

Next.js Became a Habit — Not Always a Decision

There was a time when starting a React app meant assembling your own stack — bundler, router, data fetching, architecture. Then Next.js became the go-to answer. Today, “we’re building a React app” is often followed immediately by “let’s use Next.js.” Sometimes that is the right call. More often, it is just habit.

Next.js is powerful and widely adopted, but power is not the same as fit. Three common signals that a team has reached for more framework than they actually need:

Slower feedback in large apps

As projects grow, dev startup and HMR feel heavier in Next.js compared to lighter setups like Vite — adding friction to every development cycle.

Extra mental overhead

Server Components, server/client boundaries, and server actions are powerful concepts — but not always necessary for the problem at hand. Complexity has a cost.

More framework than required

If you already have a backend and just need a frontend UI, a full-stack framework can feel like overkill — bringing infrastructure decisions that belong elsewhere.

None of these are deal-breakers in isolation. They are signals to pause and ask: do we actually need all of this?

The Right Framework Is the One That Fits Your Problem

The React ecosystem is mature enough that there is no longer one “default” framework. Three strong alternatives have emerged, each solving a different class of problem:

Vite + React
React Router v7
TanStack Start
Next.js still valid for its use case
Executive Point of View

Our point of view is: framework selection is an architectural decision that should follow the shape of your product — not the habits of your industry. Choosing a framework because it is popular is the same mistake as choosing a database because it trended on Hacker News. The question is never “what is the best framework?” It is “what am I actually building?”

Think of the ecosystem in two buckets based on what you need:

Vite + React
SPA · No SSR
A build tool, not a framework. Gives you fast dev startup, instant HMR, and complete freedom over architecture choices.

• Sub-second dev startup
• Instant hot module replacement
• Simple project structure
• Full library flexibility

Best for: Admin dashboards, internal tools, SaaS panels, authenticated UIs where SEO does not matter
React Router v7
Full-Stack · Web-First
Framework Mode turns the routing library into a full-stack framework. Routes own their data. Web fundamentals are embraced, not abstracted.

• SSR, streaming, static rendering
• Loader + Action per route
• Nested routing built-in
• Deployment adapters

Best for: SaaS products, e-commerce, portals, form-heavy and content-heavy apps
TanStack Start
Full-Stack · Type-Safe
Type-safety-first full-stack React. Routes, params, loaders, and server functions are all fully typed. No Server Components required.

• End-to-end TypeScript safety
• Server functions (no REST layer needed)
• SSR without Server Components
• Typed URL params and search params

Best for: Large TypeScript teams, complex SaaS systems — note: still maturing, evaluate before critical production use

A Simple Decision Framework for Choosing Your Stack

Forget “best framework.” Ask a simpler question: what am I actually building? Five questions that route you to the right answer:

1. Do I need SSR or public SEO?
└ No → Vite + React. Stop here.
└ Yes → Continue below.

2. Do I already have a backend API?
└ Yes → Vite. You don’t need a full-stack framework.
└ No → Continue below.

3. Is web-first architecture (forms, requests, redirects) the right mental model?
└ Yes → React Router v7 Framework Mode.
└ No → Continue below.

4. Do I need end-to-end TypeScript safety across routes and server functions?
└ Yes → Evaluate TanStack Start (check maturity for your use case).

5. Is this content-heavy, SEO-driven, or already on Vercel?
└ Yes → Next.js remains the right choice.

The Quick Comparison

Two Teams, Same Technology, Different Right Answers

The framework choice becomes concrete when you put it next to a real product decision. Here are two scenarios from the same React codebase family, with genuinely different right answers:

Scenario A — Internal Analytics Dashboard

A fintech team building an authenticated reporting UI for internal analysts. No public pages, no SEO requirement, complex data visualisations, an existing REST API. Right choice: Vite + React + TanStack Query. Adding SSR would be pure overhead — faster build, simpler mental model, no framework migration risk.

Scenario B — Customer-Facing SaaS Portal

A healthcare startup building a patient-facing portal with public marketing pages, authenticated dashboards, form-heavy workflows, and SSR requirements for initial load performance. Right choice: React Router v7 Framework Mode. Each route owns its loader and action, SSR is native, and the web-first model maps directly to their form-heavy UX.

Scenario C — Large TypeScript SaaS Platform

An enterprise team with 20+ engineers, strict TypeScript standards, a complex routing hierarchy, and internal server operations that need to stay type-safe from URL to database. Right choice: TanStack Start — with the caveat to evaluate ecosystem maturity for their specific production risk tolerance before committing.

The Pattern

In each case, the correct answer was determined by the shape of the product — not the popularity of the framework. Two of these three scenarios would have reached for Next.js by default and introduced unnecessary complexity. The discipline is asking the question before running npx create-next-app.

Four Implications for Engineering Leaders

01
Framework selection is an architectural decision, not a default. Treat it with the same deliberateness as choosing a database or a deployment model. Write down what you are building, what constraints you have, and what the framework needs to do — before selecting it.
02
Simplicity is a feature. Vite gives experienced teams full control with minimum overhead. But that freedom also means the team owns every architectural decision. It is a great fit for teams with strong conventions — and a risk for teams that have not established them yet.
03
Evaluate maturity before production commitment. TanStack Start is powerful but still evolving. For teams considering it, run a non-critical service through it first. Ecosystem maturity — available adapters, community solutions, deployment patterns — matters as much as technical capability for a production stack.
04
Next.js is still the right answer — sometimes. Content-heavy sites, SEO-driven apps, large public platforms, and teams already on Vercel have clear reasons to choose Next.js. The goal is intentionality, not avoiding it. The worst outcome is choosing any framework without asking why.

Executive Point of View
The Takeaway
The React ecosystem is mature enough that every team has the right tool for their problem. The decision should follow the product shape — not convention.
Where to Start
Before your next React project, answer five questions in writing: SSR needed? Existing backend? Web-first model? TypeScript depth required? Content or app? The framework choice follows from the answers.
What to Measure
Dev startup time, HMR speed, onboarding time for new engineers, and the number of framework-specific concepts a developer must learn before shipping their first feature.
What to Watch
TanStack Start ecosystem maturity. If it stabilises as expected, it may become the go-to for TypeScript-heavy enterprise applications within the next 12–18 months.

Key Takeaways

• If you do not need SSR, you probably do not need a full-stack framework. Vite gives you a fast, simple, flexible foundation that is often exactly enough.
• React Router v7 Framework Mode and TanStack Start are both production-ready alternatives to Next.js for full-stack React — each with different philosophies. Match the philosophy to your team’s mental model.
• The best framework is the one that fits your problem, not the one everyone else is using. Write down what you are building before you pick the tool that builds it.

Questions Teams Ask When Evaluating React Frameworks