De complex tech stacks a soluciones simples: mi regreso a lo esencial

He recorrido un largo camino en lo que respecta a tech stacks. He enviado código en producción con Golang, construido aplicaciones con Ruby on Rails, experimentado con el modelo de actores de Elixir e incluso contribuido a proyectos de código abierto. Incluso tuve que hacer backport del soporte del driver de MongoDB para Ruby y que funcionara con la autenticación SCRAM de MongoDB 2.4 porque el proyecto lo exigía.

¿Todo ese trabajo complejo e impresionante? Se quedó en las empresas donde lo construí.

Hoy, construyo todo mi directorio SaaS con Next.js y MongoDB. Y, sinceramente, mi vida nunca ha sido tan simple.

La trampa de la complejidad en la que todos caemos

Como desarrolladores, amamos las tecnologías nuevas y llamativas. Nos emocionamos con el último lenguaje de programación que promete mejor rendimiento o con la nueva base de datos que maneja casos extremos que probablemente nunca enfrentemos. Yo no era diferente.

Durante mi tiempo en varias empresas, me sumergí en:

• Golang por su concurrencia y rendimiento
• Ruby on Rails por la rapidez de prototipado y velocidad de desarrollo
• Elixir para sistemas tolerantes a fallos y distribuidos
• MongoDB a nivel interno (tanto como para modificar drivers)

Cada tecnología me enseñó algo valioso. Golang me mostró la belleza de la simplicidad en el diseño de un lenguaje. Rails me demostró cómo las convenciones pueden acelerar el desarrollo. Elixir me abrió la mente a enfoques distintos para construir sistemas resilientes.

Pero esto fue lo que aprendí: la complejidad por la complejidad misma es un asesino de la productividad.

Por qué Rails sigue siendo importante después de 21 años

Ruby on Rails se lanzó en 2004. Son 21 años de refinamiento, testing riguroso y sabiduría de la comunidad. Mientras trabajaba con Rails, noté algo importante: el framework ya había resuelto la mayoría de los problemas que intentaba solucionar con tecnologías más nuevas y "mejores".

Convención sobre configuración. Migraciones de bases de datos. Frameworks de prueba integrados. Asset pipeline. Ayudantes de autenticación. Form builders.

Rails no solo me dio herramientas. Me dio una filosofía: optimizar para la felicidad y productividad del desarrollador, no para impresionar a otros desarrolladores.

Cuando miro frameworks modernos de JavaScript como Next.js, veo el ADN de Rails en todas partes:

• Rutas basadas en archivos (¿recuerdas las rutas RESTful de Rails?)
• Rutas API integradas (Rails ya tenía esto en 2004)
• Patrones de integración con bases de datos
• Configuración basada en entornos
• Servidor de desarrollo con hot reloading

¿La diferencia? Next.js trae estos patrones probados al ecosistema de JavaScript, donde puedo usar un solo lenguaje para todo.

El poder de la restricción

Este es mi stack actual para construir aplicaciones SaaS:

• Frontend & Backend: Next.js con TypeScript y React
• Base de datos: MongoDB con Prisma
• Búsqueda: Typesense (self-hosted)
• Estilos: Tailwind CSS
• Despliegue: Google Cloud Run con Terraform (aunque también uso Vercel en algunos proyectos)

Eso es todo. Cinco tecnologías principales, un solo lenguaje en toda la pila.

El modelo de componentes de React se ha convertido en el estándar para pensar en interfaces de usuario. Después de años de trabajar con diferentes sistemas de plantillas y frameworks de UI, el enfoque declarativo de React simplemente tiene sentido. Los componentes son predecibles, testeables y reutilizables.

Pero el verdadero cambio de juego es tener TypeScript en todas partes. Consultas a la base de datos, rutas API, componentes de React, funciones utilitarias: todo habla el mismo lenguaje. Nada de cambiar de contexto entre Ruby en el backend y JavaScript en el frontend. Sin sobrecarga mental de recordar distintos patrones de sintaxis.

Tailwind CSS completa esta experiencia unificada. En lugar de mantener archivos CSS separados o pelearme con soluciones CSS-in-JS, estoy dando estilo directamente en el marcado con clases utilitarias. Es rápido, consistente y, combinado con los componentes de React, crea una experiencia de desarrollo que fluye.

Para el despliegue, me quedo con Google Cloud Run y Terraform. Una vez que aprendes las herramientas de infraestructura y entiendes cómo funcionan, es difícil renunciar a ese control y flexibilidad. Aunque debo admitir que la simplicidad de Vercel es tentadora para proyectos pequeños donde solo quiero subir código y olvidarme.

Esta restricción me obliga a resolver problemas en lugar de investigar soluciones. Cuando tenía acceso a múltiples lenguajes y frameworks, pasaba horas debatiendo si usar Postgres o MongoDB, si construir la API en Golang o mantenerla en JavaScript, si probar la última biblioteca de gestión de estado.

¿Ahora? Escribo TypeScript. Guardo datos en MongoDB. Despliego en Vercel. Listo.

Cómo se ve realmente la simplicidad

Con mi stack simple, puedo:

• Construir una funcionalidad completa, desde el esquema de la base de datos hasta la interfaz de usuario, en un solo día y todo en TypeScript
• Depurar problemas sin cambiar de contexto entre lenguajes o modelos mentales
• Dar estilo a los componentes con Tailwind sin salir del JSX
• Integrar nuevos miembros al equipo sin tener que explicar seis tecnologías diferentes
• Desplegar cambios sin coordinar múltiples servicios
• Mantener aplicaciones sin un equipo de DevOps

La combinación del modelo de componentes de React, la seguridad de tipos de TypeScript y el enfoque utilitario de Tailwind crea una experiencia de desarrollo donde todo se siente conectado. No estoy saltando entre una API en Ruby, un frontend en JavaScript y archivos CSS separados. Es un flujo cohesivo de datos a interfaz de usuario.

La combinación MongoDB + Prisma realmente brilla aquí. Aunque aprecio la estructura que proporcionan las bases de datos SQL, el modelo de documentos de MongoDB se adapta de forma natural a los objetos de JavaScript, y Prisma ofrece una integración excelente con TypeScript sin la complejidad de los ORM tradicionales. Nada de migraciones de esquema por cada cambio pequeño. Solo datos que se ven como el código que los usa, con seguridad de tipos completa.

Una técnica que he adoptado es la desnormalización deliberada de datos en MongoDB. Este enfoque se inspiró en mi experiencia con DynamoDB, donde la desnormalización no solo es común, es esencial para el rendimiento.

Mi enfoque actual es híbrido: almaceno datos normalizados para escrituras, pero mantengo colecciones desnormalizadas optimizadas para lecturas. Sí, esto significa ejecutar pequeños procesos de recálculo cuando los datos cambian, pero las ganancias en rendimiento lo justifican.

Para mi directorio SaaS, uso Prisma para las operaciones de escritura normalizadas, luego lleno colecciones desnormalizadas optimizadas para la navegación. Como un directorio no necesita actualizaciones en tiempo real (si una app recibe una reseña nueva, está bien que aparezca en los resultados de búsqueda unos minutos después), esta consistencia eventual funciona perfectamente.

La belleza de este patrón es su simplicidad para entender y mantener. Cuando depuro o agrego funcionalidades, el flujo de datos es claro como el agua. Incluso herramientas de IA como Claude Code funcionan mejor con este enfoque sencillo: no se confunden con relaciones complejas ni alucinan optimizaciones extrañas cuando el patrón es así de explícito.

La sobrecarga de recálculo es mínima, y siendo honesto, no puedo evitarlo cuando se trata de optimizaciones de consultas. Una vez que empiezas a pensar en rendimiento, es difícil parar. Pero al menos con este stack simple, mis tendencias a sobre-ingeniería están contenidas al modelado de datos en lugar de dispersarse entre cinco tecnologías diferentes.

El costo oculto de la diversidad técnica

Déjame darte un ejemplo real. Una vez construí un sistema POS (Point of Sale) en Elixir. Era hermoso. Tolerante a fallos, concurrente, manejando miles de transacciones sin sudar. Los supervisores OTP significaban que si un proceso fallaba, el sistema reiniciaba ese componente y seguía funcionando. Pura elegancia de ingeniería.

¿Hoy? Nadie puede mantenerlo.

El sistema es demasiado robusto para su propio bien. Rara vez falla, lo que significa que el equipo nunca necesitó aprender Elixir a fondo. Cuando se necesitan pequeños cambios, no pueden hacerlos con confianza. Los pocos desarrolladores de Elixir en nuestra área cobran el doble que los desarrolladores de JavaScript.

Eventualmente reemplazaré este sistema a prueba de balas con algo construido en un stack más común. No porque Elixir sea malo, sino porque la sostenibilidad supera a la excelencia técnica.

Este patrón se repitió en todas partes donde trabajé. Los microservicios en Golang requerían alguien que entendiera el runtime de Go. Las aplicaciones en Ruby requerían experiencia en Rails. Cuando los miembros del equipo se iban, el conocimiento institucional se iba con ellos.

¿Mis aplicaciones simples en Next.js? Cualquier desarrollador de JavaScript puede entenderlas y extenderlas. La barrera de entrada es más baja. La carga de mantenimiento es más ligera. La sostenibilidad a largo plazo es mayor.

El desarrollo moderno aprovecha 21 años de lecciones

La razón por la que mi stack simple funciona tan bien es porque se sostiene sobre hombros de gigantes. Next.js no reinventó el desarrollo web. Tomó las mejores ideas de Rails, Django y otros frameworks maduros y las adaptó al ecosistema JavaScript.

MongoDB no creó bases de datos de documentos desde cero. Aprendió de décadas de diseño de bases de datos y construyó algo que funciona mejor para los patrones modernos de desarrollo de aplicaciones.

TypeScript no ignoró 30 años de investigación en sistemas de tipos. Trajo conceptos probados de seguridad de tipos al lenguaje dinámico que los desarrolladores ya usaban.

Este es el secreto: las mejores herramientas modernas no son revolucionarias. Son evolutivas. Toman conceptos probados en batalla y los hacen accesibles en nuevos contextos.

Mirando hacia adelante: orientado a eventos sin el caos

Actualmente estoy explorando una evolución de este stack simple: moverme hacia una arquitectura orientada a eventos usando Next.js + Google Cloud + N8N. La idea es mantener la simplicidad que amo mientras agrego los beneficios de sistemas asíncronos y débilmente acoplados.

N8N maneja la orquestación de flujos de trabajo, Google Cloud me da la infraestructura que ya entiendo y Next.js sigue siendo la base familiar. Es una progresión natural que se apoya en lo que ya sé en lugar de forzarme a aprender paradigmas completamente nuevos.

Así es como funcionan las decisiones tecnológicas sostenibles: pasos pequeños y deliberados que se construyen sobre el conocimiento existente en lugar de reescrituras dramáticas que tiran años de aprendizaje.

Cuando la simpleza gana

No digo que las arquitecturas complejas siempre estén mal. Si estás construyendo sistemas distribuidos para millones de usuarios, puede que necesites esa complejidad. Si trabajas en dominios especializados como trading financiero en tiempo real o sistemas embebidos, las herramientas especializadas tienen sentido.

Pero para la mayoría de aplicaciones SaaS, aplicaciones web y MVPs de startups, la simpleza gana.

Mi directorio SaaS atiende usuarios y resuelve problemas reales. Y lo construí con tecnologías que cualquier desarrollador de JavaScript puede entender y mantener.

Eso no solo es buen negocio. Es desarrollo sostenible.

El stack que realmente pone cosas a producción

Después de años explorando diferentes tecnologías, he aprendido que el mejor stack es el que pone tus ideas en manos de los usuarios más rápido. Para mí, ese es Next.js y MongoDB.

No porque sean los más eficientes. No porque sean los más elegantes. Sino porque me permiten enfocarme en resolver problemas de clientes en lugar de problemas de tecnología.

Y al final del día, a los clientes no les importa qué está corriendo en tus servidores. Les importa si tu aplicación les ayuda a hacer su trabajo.

Mi stack simple hace exactamente eso.