¿Por qué tener un stack "default"?
Cuando construís muchos proyectos para clientes distintos, en plazos distintos y con presupuestos distintos, una de las decisiones más valiosas que podés tomar es estandarizar tu stack. No porque no existan alternativas mejores para ciertos casos, sino porque la productividad que ganás al conocer profundamente un conjunto de herramientas vale más que el beneficio marginal de usar la tecnología "perfecta" para cada problema.
Este es el stack que uso hoy en Deepyze para la mayoría de los proyectos. No es el único válido ni el mejor para todos los casos. Es el que me permite entregar valor rápido y mantener el código a largo plazo.
Frontend: React con Vite y Tailwind CSS
React sigue siendo mi primera opción para frontend. No porque sea el framework más moderno —hay argumentos válidos para Vue, Svelte o solid.js— sino porque su ecosistema es el más maduro y la cantidad de problemas ya resueltos es enorme.
Uso Vite como bundler. La diferencia en tiempo de arranque y hot reload comparado con Create React App es brutal. Para proyectos donde el SEO importa mucho, evalúo Next.js, aunque para sitios estáticos prefiero react-snap sobre una app Vite antes de meter la complejidad de SSR.
Para estilos, Tailwind CSS cambió completamente cómo trabajo. La velocidad para maquetar es incomparable y la consistencia visual que lográs con el sistema de design tokens es difícil de replicar con CSS plano. El único punto en contra: los classnames largos en componentes complejos. Lo mitigo con componentes bien abstraídos y la directiva @apply para patrones repetidos.
Complemento con Framer Motion para animaciones de UI y GSAP para animaciones más complejas ligadas al scroll.
Backend: Node.js con Express
Node.js con Express es mi backend de referencia para el 90% de los proyectos. Simple, bien conocido, enorme ecosistema de paquetes en npm, y JavaScript en ambos lados de la pila: una sola mentalidad para todo el proyecto.
La estructura que uso es bastante estándar: routes/, controllers/, models/, middleware/, services/. Separo la lógica de negocio en services para que las rutas sean simples adaptadores HTTP. Esto hace que el código sea testeable y mantenible.
Para autenticación uso JWT en la mayoría de los casos. Para proyectos con múltiples roles o permisos complejos, agrego una capa de RBAC sobre los middlewares de Express.
Base de datos: MongoDB (con Mongoose)
MongoDB es mi base de datos default para proyectos nuevos. La razón principal no es técnica sino práctica: la flexibilidad del esquema en las fases tempranas de un producto es invaluable. Cuando todavía estás descubriendo qué datos necesitás, poder cambiar la estructura de un documento sin migraciones costosas acelera mucho el desarrollo.
Uso Mongoose para el ODM. Me da validación de esquema, hooks de pre/post, índices declarativos y una API limpia para queries.
Cuándo cambiaría a PostgreSQL: cuando el proyecto tiene relaciones complejas entre entidades que se consultan juntas frecuentemente (joins), cuando la consistencia transaccional es crítica (fintech, legal), o cuando el equipo ya tiene experiencia sólida con SQL.
Mobile: React Native con Expo
Para apps mobile, React Native con Expo es mi stack. Compartir lógica de negocio entre web y mobile, y escribir todo en JavaScript, reduce enormemente el costo de desarrollo. Expo Router simplificó el routing en los últimos años y el soporte para features nativas mejoró mucho.
Infraestructura y deploys
Para backends en producción uso AWS EC2 con PM2 para gestión de procesos. Para frontends estáticos, Vercel es imbatible en simplicidad. Las imágenes van a Cloudinary, que maneja optimización y transformaciones sin configuración adicional.
Lo que cambiaría si empezara hoy
Si empezara un proyecto greenfield hoy con tiempo para aprender, consideraría seriamente Next.js App Router para proyectos donde el SEO es crítico y Prisma + PostgreSQL para proyectos con datos relacionales desde el día uno. Pero para la mayoría de los proyectos de clientes, React + Node + Mongo sigue siendo la combinación más rápida de entregar.