Elegir mal el stack es uno de los errores más caros en software. No porque la tecnología sea «mala», sino porque no encaja con el trabajo. Una startup construida sobre Java EE tardará un año en lanzarse en lugar de tres meses. Un producto fintech de alta carga sobre WordPress no aguantará 1.000 transacciones simultáneas. Según CB Insights, el 18% de las startups cita «el producto o la tecnología equivocados» entre las causas de su fracaso, la tercera razón más común tras la falta de demanda en el mercado y quedarse sin dinero.
Este artículo es para quienes toman las decisiones (CEO, CTO, product owner), no para desarrolladores que discuten sobre React vs Vue. Veremos qué criterios importan de verdad, qué stacks encajan con qué proyectos y cómo evitar quedarte atrapado con una tecnología de moda que nadie sabe mantener.
7 criterios para elegir un stack (por orden de importancia)
Antipatrón: «a nuestro CTO le encanta Haskell». Las preferencias personales son la peor forma de elegir un stack. Cuando ese CTO se vaya, te quedarás con una base de código en Haskell y sin desarrolladores a los que contratar. Elige el stack con criterios de negocio, no según la afición de tu director técnico.
Frontend: React, Vue, Angular y cuándo usar cada uno
React (Next.js)
Cuándo elegirlo: en el 70% de los proyectos. El ecosistema más grande, el mayor número de desarrolladores en el mercado y sirve para cualquier tipo de interfaz. Next.js añade SSR/SSG para el SEO, API routes y optimización integrada.
Coste de los desarrolladores: React tiene la mayor cantera de talento, así que contratar es más fácil en todos los niveles, de junior a senior. Un desarrollador con experiencia en plantilla cuesta unos 6.000 €/mes con cargas sociales.
Un ejemplo real: en March Code usamos Next.js + React como stack principal para aplicaciones web. Esta web, las webs corporativas y los paneles de clientes funcionan con Next.js.
Vue (Nuxt)
Cuándo elegirlo: si tu equipo ya domina Vue o el proyecto es relativamente sencillo (un panel de administración, un portal interno). La curva de aprendizaje es más suave que la de React y la documentación es excelente. Pero el ecosistema es más pequeño y hay menos desarrolladores en el mercado.
Coste de los desarrolladores: un 10–15% menor que con React (menos demanda, sueldos más bajos).
Angular
Cuándo elegirlo: grandes proyectos corporativos con 5 o más desarrolladores frontend. Angular impone una arquitectura estricta (DI, módulos, servicios): bien para equipos grandes, excesivo para los pequeños. TypeScript por defecto. Respaldado por Google.
Cuándo NO elegirlo: startups, MVP, proyectos pequeños. Angular necesita 2–3 veces más código repetitivo que React o Vue.
Sin framework (HTMX, Alpine.js)
Cuándo elegirlo: webs de contenido, landing pages, aplicaciones renderizadas en servidor con poca interactividad. HTMX + renderizado en servidor (Django, Laravel, Rails) es más potente de lo que parece. Sin paso de build, sin el zoo de npm, con un mínimo de JS.
Backend: Node.js, Python, Go, Java, PHP
Node.js (NestJS, Express, Fastify)
A favor: un solo lenguaje en frontend y backend (JS/TS), el enorme ecosistema de npm y un manejo asíncrono excelente para trabajo intensivo en E/S. En contra: un solo hilo (las tareas intensivas en CPU lo ralentizan), el «callback hell» en el código antiguo y la calidad desigual de los paquetes de npm. Ideal para: servicios API, aplicaciones en tiempo real (chats, notificaciones), BFF (Backend for Frontend).
Python (Django, FastAPI)
A favor: legibilidad, velocidad de desarrollo, el mejor ecosistema para ML/IA, y Django viene «con las pilas incluidas». En contra: más lento que Node.js o Go en benchmarks puros (algo que no importa en el 90% de las tareas). Ideal para: MVP, analítica, proyectos de ML, API REST, productos de IA.
Go
A favor: velocidad (cercana a C), bajo consumo de recursos, concurrencia integrada (goroutines), tipado estático. En contra: menos desarrolladores en el mercado, un ecosistema más escaso (nada comparable a Django o Rails). Ideal para: microservicios, API de alta carga, servicios de infraestructura, herramientas CLI.
Java (Spring Boot)
A favor: madurez (más de 25 años), un ecosistema enterprise (Spring, Hibernate), la optimización de la JVM y muchos desarrolladores. En contra: verbosidad (mucho código), alto consumo de memoria, compilación lenta. Ideal para: banca, seguros, ERP/CRM corporativos, grandes sistemas desarrollados por equipos de 10 o más personas.
PHP (Laravel)
A favor: el hosting más barato, muchísimos desarrolladores, y Laravel es un framework elegante. En contra: su reputación (aunque PHP 8.3 es un lenguaje perfectamente moderno) y un techo de rendimiento más bajo. Ideal para: e-commerce, webs de contenido, CMS, cuando el presupuesto es ajustado y necesitas arrancar rápido.
Si no sabes qué elegir, ve a por Node.js (NestJS) o Python (Django/FastAPI). Cubren el 80% de las tareas de negocio, tienen la mayor cantidad de desarrolladores en el mercado y escalan a más de 100.000 usuarios con la arquitectura adecuada. Go y Java, para cuando sabes exactamente por qué los necesitas.
Bases de datos: PostgreSQL, MongoDB, Redis
PostgreSQL
La opción por defecto en el 90% de los proyectos. Relacional y con transacciones ACID, admite JSON (datos no relacionales), búsqueda de texto completo, datos geográficos (PostGIS) y embeddings vectoriales (pgvector para IA). Gratis. Si dudas, elige PostgreSQL.
MongoDB
Una base de datos documental. Buena para logs, datos de analítica, contenido con estructura libre y prototipos. Mala para sistemas transaccionales (finanzas, pedidos) y datos con relaciones complejas. En el 80% de los casos en que un equipo elige MongoDB, PostgreSQL habría hecho mejor el trabajo.
Redis
Un almacén en memoria. Se usa como caché (sesiones, consultas frecuentes), cola de mensajes, pub/sub. No sustituye a tu base de datos principal; la complementa. Acelera la aplicación entre 10 y 100 veces con datos que se pueden cachear.
ClickHouse
Una base de datos columnar open source para analítica. En consultas OLAP (analítica, informes, paneles), es entre 100 y 1.000 veces más rápida que PostgreSQL. No está pensada para operaciones transaccionales (CRUD). Úsala junto a PostgreSQL para la analítica.
Infraestructura: Docker, Kubernetes, la nube
Docker
Los contenedores son el estándar en 2026. Docker garantiza que «si funciona en mi máquina, funciona en el servidor». Para el 90% de los proyectos, Docker + docker-compose es suficiente. Coste: 0 € (open source) más un VPS desde unos 9 €/mes.
Kubernetes
Orquestación de contenedores. Lo necesitas con 10 o más microservicios, autoescalado (carga que varía 10 veces o más) o requisitos de alta disponibilidad (99,99% o más). No lo necesitas para un monolito, un equipo sin ingeniero DevOps o un presupuesto de menos de 13.500 €. Kubernetes añade complejidad, así que asegúrate de que te compensa.
Plataformas cloud
AWS: el líder del mercado, con el mayor catálogo de servicios gestionados. Google Cloud y Azure: alternativas sólidas; Azure encaja de forma natural si ya trabajas con Microsoft 365 y .NET. Hetzner, DigitalOcean: servidores dedicados (bare metal) y VPS con una relación precio/rendimiento excelente. Residencia de los datos: si el RGPD o la normativa de tu sector exigen que los datos se queden en una región concreta, elige esa región (o un proveedor local) desde el primer día.
Recomendaciones por tipo de proyecto
MVP / startup
Stack: Next.js + NestJS (o FastAPI) + PostgreSQL + Docker + un VPS. Por qué: máxima velocidad de desarrollo, un solo lenguaje (TypeScript) en frontend y backend, hosting barato. Pasa a un stack más «serio» cuando tengas product-market fit y dinero.
E-commerce
Stack: Next.js + Node.js (NestJS) + PostgreSQL + Redis + Elasticsearch. Por qué: SSR para el SEO, Redis para cachear el catálogo, Elasticsearch para la búsqueda. Alternativa: Laravel + Vue, si necesitas arrancar rápido con menos presupuesto. Más en nuestro artículo sobre cómo crear una tienda online.
Sistema corporativo (ERP, CRM)
Stack: React + Java (Spring Boot) o .NET + PostgreSQL + RabbitMQ. Por qué: tipado estricto, librerías enterprise, fiabilidad transaccional. Si tu contabilidad ya funciona con un programa estándar (Holded, A3, Sage), mantenlo como núcleo contable y construye a su alrededor una interfaz a medida.
Producto de IA/ML
Stack: React + Python (FastAPI) + PostgreSQL + Redis + Celery. Por qué: Python es la única opción sensata para un backend de ML (TensorFlow, PyTorch, scikit-learn, LangChain). FastAPI es asíncrono, rápido y tipado.
App móvil
Stack: Flutter o React Native + Node.js/Python + PostgreSQL. Por qué: desarrollo multiplataforma (iOS + Android con una sola base de código). Elegir entre Flutter y React Native depende de lo cerca de lo nativo que tenga que sentirse la UX.
Preguntas frecuentes sobre cómo elegir el stack
¿Se puede cambiar de stack después del lanzamiento?
Técnicamente, sí. En la práctica, cuesta 2–3 veces el desarrollo original y lleva 3–12 meses. El frontend es más fácil de sustituir (de React a Vue: 1–2 meses). El backend, más difícil (de Python a Go: 3–6 meses, porque se reescribe toda la lógica). La base de datos es lo más doloroso (migración de datos, cambios de estructura).
¿Conviene usar microservicios desde el principio?
No. Empieza con un monolito (o un «monolito modular»). Los microservicios compensan cuando tienes 10 o más desarrolladores, distintos lenguajes o stacks en distintas partes del sistema, o la necesidad de escalar componentes por separado. En el 90% de los proyectos, un monolito es el comienzo correcto.
¿Qué importa más: la velocidad de desarrollo o el rendimiento?
Para un MVP o una startup, la velocidad. Para sistemas de alta carga (más de 1.000 RPS), el rendimiento. Para todo lo demás, velocidad de desarrollo más optimizar los cuellos de botella. La optimización prematura es el mal: te pasarás un mes consiguiendo un 10% de velocidad que nadie nota.
¿Cómo valorar si un proveedor domina un stack?
Pregúntale por qué ha elegido ese stack (la respuesta debe salir del problema de negocio, no de «es a lo que estamos acostumbrados»), qué alternativas ha considerado y qué problemas prevé y cómo los resolverá. Un proveedor que dice «lo hacemos todo en [una sola tecnología]» es una señal de alarma. Más en cómo elegir una empresa de desarrollo.
¿Qué importancia tiene TypeScript?
Es crítico en cualquier proyecto con 2 o más desarrolladores. TypeScript detecta el 30–40% de los bugs en tiempo de compilación, antes de que lleguen a los usuarios. Un desarrollador que trabaja solo en un prototipo puede apañarse con JavaScript, pero a medida que el proyecto crece, TypeScript ahorra cientos de horas de depuración.
¿Conviene usar plataformas low-code/no-code?
Para prototipos y herramientas internas, sí (Retool, Bubble, AppSheet). Para un producto en producción, no. El low-code limita la personalización, te ata a la plataforma (vendor lock-in) y escala mal. Úsalo para validar la idea y luego reconstruye sobre un stack de verdad.
