Por qué elegí Next.js para mi último SaaS

Cuando empiezo un producto SaaS, no empiezo preguntándome qué stack está más de moda. Me hago una pregunta más estrecha: ¿qué me dejará shippear rápido sin crear lastre innecesario dentro de seis meses? Para mi último producto, la respuesta fue Next.js.

Eso no significa que Next.js sea perfecto, ni que sea la elección correcta para cada app. Significa que sus trade-offs encajaban con el tipo de producto que quería construir: flujos autenticados, dashboards, formularios, páginas de contenido y un sitio público de marketing viviendo en el mismo codebase.

Este es el razonamiento práctico detrás de esa elección.

Quería un framework para toda la superficie del producto

La mayoría de productos SaaS no son solo "una app". Son varias superficies pegadas entre sí:

una landing page
un dashboard autenticado
flujos de settings y billing
formularios y pasos de onboarding
estados transaccionales de UI como loading, empty y error screens

No quería ensamblar routing, data fetching, layouts, metadata y deployment desde librerías separadas salvo que tuviera una buena razón. Next.js me da un default coherente para todo eso.

El valor no es solo conveniencia. Es menos overhead de decisiones. Un framework con opiniones fuertes ahorra tiempo cada semana porque deja menos preguntas arquitectónicas abiertas.

App Router encaja con cómo pienso la estructura de producto

El App Router es una de las mayores razones por las que sigo eligiendo Next.js para trabajo SaaS.

Los layouts anidados no son solo una neat feature técnica. Reflejan cómo están organizados los productos de verdad. Las páginas públicas tienen un shell. Las áreas logueadas tienen otro. Las páginas de settings suelen compartir un sidebar. Las páginas de marketing comparten un wrapper más ligero y distinta metadata.

Con route groups y layouts, el codebase empieza a reflejar el mapa del producto en vez de pelear contra él.

Eso importa porque la mantenibilidad suele ser un problema de estructura antes de ser un problema de performance.

El renderizado server-first sirve para productos reales

Una de las formas más fáciles de sobrecomplicar un frontend SaaS es fetchear todo en el cliente por defecto.

Ese enfoque funciona, pero suele crear estados de carga extra, lógica de fetching duplicada y más JavaScript del necesario al inicio. Next.js me empuja hacia un mejor default:

renderizar en el servidor lo que se pueda renderizar en el servidor
reservar los componentes de cliente para la interactividad
mover el acceso a datos cerca de donde se usa

Esa división no siempre es trivial, pero lleva a boundaries más limpios.

Para dashboards, páginas autenticadas y pantallas con mucho contenido, este modelo es práctico. La vista inicial carga con datos útiles ya presentes. Los usuarios ven menos flicker de UI. Yo paso menos tiempo construyendo coreografías de placeholders para datos que podrían haber llegado con la respuesta.

La developer experience es lo bastante rápida como para importar

Me importan mucho los feedback loops. Si el ciclo edit-save-refresh es lento, el producto sufre porque el equipo shippea menos y experimenta menos.

Next.js no es el framework más ligero del planeta, pero la velocidad de iteración general sigue siendo fuerte:

el filesystem routing mantiene la navegación predecible
co-locar UI y lógica de ruta reduce la caza de archivos
el soporte built-in de TypeScript minimiza el setup
metadata, imágenes y assets estáticos tienen convenciones claras

El punto clave es este: mucho tiempo de ingeniería no se pierde resolviendo problemas difíciles, sino re-resolviendo problemas de framework ya resueltos. Prefiero gastar ese tiempo en decisiones de producto.

Encaja con el stack que ya uso

Mi stack frontend por defecto suele ser alguna combinación de:

Next.js
TypeScript
Tailwind CSS
una capa de componentes que controlo
servicios backend como Supabase, Postgres o APIs custom

Next.js encaja cómodamente en ese setup.

TypeScript es first-class. Tailwind funciona natural. El renderizado del lado del servidor y los route handlers me dan margen para auth edges, lógica backend ligera y trabajo de integraciones sin inventar una capa separada demasiado pronto.

Eso no reemplaza un backend real cuando hace falta. Solo significa que puedo empezar con menos piezas móviles e introducir complejidad cuando el producto realmente la gane.

Hace el trabajo de performance más deliberado

Hay un argumento perezoso sobre frameworks: "maneja la performance por ti". Eso nunca es del todo cierto.

Lo que Next.js sí me da es un mejor set de defaults:

code splitting por rutas
server rendering cuando ayuda
streaming y suspense donde toca
optimización de imágenes y primitivas de metadata

Igual tienes que diseñar buenas páginas. Igual tienes que evitar shippear bundles gigantes de cliente. Igual tienes que prestar atención a los boundaries de estado y a los scripts de terceros.

Pero prefiero partir de un framework que me empuja hacia la contención que de uno que deja cada decisión de performance como opcional y fácil de posponer.

La historia de deployment es simple

La simplicidad operativa importa más de lo que la gente admite.

Cuando construyo un SaaS early-stage, quiero un modelo de deployment aburrido:

preview deployments por cada cambio
manejo claro de variables de entorno
rollback fácil
comportamiento predecible de renderizado estático y dinámico

Next.js me da ese workflow con muy poca ceremonia. Eso importa porque el trabajo de producto ya está lleno de incertidumbre. No quiero que el setup de infra se convierta en una segunda startup dentro de la startup.

Los trade-offs son reales

No elijo Next.js porque crea que no tiene downsides.

Hay trade-offs reales:

el comportamiento del framework puede sentirse mágico hasta que aprendes los límites
los splits servidor/cliente requieren disciplina
el caching y la revalidación pueden ser sutiles
los upgrades pueden traer churn, sobre todo en canary o versiones que se mueven rápido

Si estuviera construyendo un frontend muy especializado con constraints de renderizado inusuales, o si necesitara una abstracción más fina, quizá elegiría otra cosa.

Pero para un SaaS típico, esos trade-offs son aceptables porque el upside es sustancial: delivery más rápido con una arquitectura default más fuerte.

Por qué lo elegí, en una línea

Elegí Next.js porque me deja construir toda la superficie de un SaaS dentro de un sistema opinionado sin renunciar a la flexibilidad que me importa.

Esa es la razón real. Ni hype. Ni presión de tendencias. Solo leverage.

El framework me ayuda a pasar más tiempo en lo que los usuarios notan: onboarding, velocidad, claridad, workflows y calidad de producto. Y para un negocio SaaS, esa es la parte que importa.

When I start a SaaS product, I do not begin by asking what stack is most fashionable. I ask a narrower question: what will let me ship fast without creating unnecessary drag six months later? For my latest product, the answer was Next.js.

That does not mean Next.js is perfect, or that it is the right choice for every app. It means its trade-offs matched the kind of product I wanted to build: authenticated flows, dashboards, forms, content pages, and a public marketing site living in the same codebase.

Here is the practical reasoning behind that choice.

I wanted one framework for the entire product surface

Most SaaS products are not just “an app.” They are several surfaces glued together:

a landing page
an authenticated dashboard
settings and billing flows
forms and onboarding steps
transactional UI states like loading, empty, and error screens

I did not want to assemble routing, data fetching, layouts, metadata, and deployment from separate libraries unless I had a strong reason to. Next.js gives me a coherent default for all of that.

The value is not only convenience. It is reduced decision overhead. A framework with a strong opinion saves time every week because fewer architectural questions stay open.

App Router matches how I think about product structure

The App Router is one of the biggest reasons I keep reaching for Next.js in SaaS work.

Nested layouts are not just a neat technical feature. They mirror how products are actually organized. Public pages have one shell. Logged-in product areas have another. Settings pages often share a sidebar. Marketing pages share a lighter wrapper and different metadata.

With route groups and layouts, the codebase starts to reflect the product map instead of fighting it.

That matters because maintainability is often a structure problem before it becomes a performance problem.

Server-first rendering is useful for real products

One of the easiest ways to overcomplicate a SaaS frontend is to fetch everything on the client by default.

That approach works, but it usually creates extra loading states, duplicated fetching logic, and more JavaScript than the user needs up front. Next.js pushes me toward a better default:

render what can be rendered on the server
keep client components for interactivity
move data access closer to where it is used

That split is not always trivial, but it leads to cleaner boundaries.

For dashboards, authenticated pages, and content-heavy screens, this model is practical. The initial view loads with useful data already present. Users see less UI flicker. I spend less time building placeholder choreography for data that could have arrived with the response.

The developer experience is fast enough to matter

I care a lot about feedback loops. If the edit-save-refresh cycle is slow, the product suffers because the team ships less and experiments less.

Next.js is not the lightest framework on earth, but the overall iteration speed is still strong:

filesystem routing keeps navigation predictable
co-locating UI and route logic reduces file hunting
built-in TypeScript support keeps setup minimal
metadata, images, and static assets have clear conventions

The key point is this: a lot of engineering time is lost not in solving hard problems, but in re-solving solved framework problems. I would rather spend that time on product decisions.

It fits the stack I already use

My default frontend stack is usually some combination of:

Next.js
TypeScript
Tailwind CSS
a component layer I control
backend services like Supabase, Postgres, or custom APIs

Next.js sits comfortably in that setup.

TypeScript is first-class. Tailwind works naturally. Server-side rendering and route handlers give me room to handle auth edges, lightweight backend logic, and integration work without inventing a separate layer too early.

That does not replace a real backend when one is needed. It just means I can start with fewer moving parts and introduce complexity when the product actually earns it.

It makes performance work more deliberate

There is a lazy argument people make about frameworks: “it handles performance for you.” That is never fully true.

What Next.js does give me is a better set of defaults:

code splitting through routes
server rendering when it helps
streaming and suspense where appropriate
image optimization and metadata primitives

You still have to design good pages. You still have to avoid shipping massive client bundles. You still have to pay attention to state boundaries and third-party scripts.

But I would rather start from a framework that nudges me toward restraint than from one that makes every performance decision optional and easy to postpone.

The deployment story is simple

Operational simplicity matters more than people admit.

When I am building an early-stage SaaS, I want a deployment model that is boring:

preview deployments for every change
clear environment variable handling
easy rollback
predictable static and dynamic rendering behavior

Next.js gives me that workflow with very little ceremony. That matters because product work is already full of uncertainty. I do not want infrastructure setup to become a second startup inside the startup.

The trade-offs are real

I do not choose Next.js because I think it has no downsides.

There are real trade-offs:

framework behavior can feel magical until you learn the boundaries
server/client splits require discipline
caching and revalidation can be subtle
upgrades can introduce churn, especially on canary or fast-moving versions

If I were building a highly specialized frontend with unusual rendering constraints, or if I needed a thinner abstraction, I might choose something else.

But for a typical SaaS product, those trade-offs are acceptable because the upside is substantial: faster delivery with a stronger default architecture.

Why I picked it, in one line

I chose Next.js because it lets me build a full SaaS surface area inside one opinionated system without giving up the flexibility I care about.

That is the real reason. Not hype. Not trend pressure. Just leverage.

The framework helps me spend more time on what users notice: onboarding, speed, clarity, workflows, and product quality. And for a SaaS business, that is the part that matters.