Mi stack favorito para proyectos grandes

Cuando un proyecto crece más allá del prototipo —backend, frontend, móvil, escritorio, IA y despliegue— elegir las herramientas correctas desde el inicio marca la diferencia entre un sistema cómodo de mantener y un infierno de dependencias. Este es mi stack.

Hay muchos artículos que hablan de "el mejor stack", pero la mayoría se quedan en el frontend o en el backend. La realidad de un proyecto grande es que necesitas tomar decisiones coherentes en todas las capas: base de datos, API, interfaz web, aplicación móvil, herramienta de escritorio, integración de IA y pipeline de despliegue.

Este artículo resume el ecosistema de herramientas que prefiero estos días cuando afronto proyectos de ese nivel. No es la única forma de hacerlo, pero sí es la que mejor equilibrio me da entre rendimiento, experiencia de desarrollo y capacidad de trabajar en equipo.

Stack de un vistazo

1. Base de datos

La elección de la base de datos depende del tipo de datos y del esquema del proyecto. No existe una sola respuesta correcta, pero sí hay una jerarquía de preferencias según el caso de uso.

PostgreSQL — el 80% de los casos

Para la gran mayoría de proyectos de producción, PostgreSQL es mi primera elección. Es la base de datos SQL más popular del mundo por buenas razones: robusta, con un ecosistema enorme de servicios de hosting (Railway, Supabase, Neon, RDS), y extremadamente fácil de desplegar. Si el esquema está bien definido, Postgres es la respuesta.

MongoDB — cuando el esquema es dinámico

Hay proyectos en los que los datos no tienen una estructura fija, especialmente cuando se integran herramientas de IA que generan información con distintos formatos. En esos casos, MongoDB es mi equivalente de Postgres en el mundo NoSQL: igualmente popular, bien soportado y con buenas opciones de hosting.

SQLite — para herramientas y sistemas internos

SQLite parece una base de datos "pequeña", pero es subestimada. Para sistemas que no son controlados por múltiples usuarios simultáneamente —una herramienta CLI, un sistema propio, una integración con N8N— SQLite es imbatible: cabe en un archivo, consume kilobytes de espacio, sus procesos son mínimos y funciona sin problema en una Raspberry Pi. Incluso soporta foreign keys y hacer un backup es trivial.

Redis — caché en memoria

Redis no reemplaza a PostgreSQL; lo complementa. Mientras Postgres guarda los datos en disco (SSD), Redis los guarda en RAM. La RAM es órdenes de magnitud más rápida de leer, por lo que guardar en Redis las respuestas más solicitadas permite reducir drásticamente la latencia. Solo las peticiones más frecuentes viven en Redis; el resto sigue en la base de datos principal.

💡 En el 80% de mis proyectos uso PostgreSQL + Redis. MongoDB entra cuando el esquema es muy dinámico o cuando trabajo con datos no estructurados de IA.

2. Backend

TypeScript y Python son dos lenguajes excelentes para el backend y los uso en proyectos de clientes. TypeScript permite compartir lógica (tipos, validaciones) con el frontend; Python es inevitable cuando necesitas bibliotecas de Data Science o IA.

Pero si me preguntan qué lenguaje elegiría hoy para un proyecto nuevo, especialmente con asistencia de IA para escribir código, la respuesta es Go.

¿Por qué Go?

Go tiene un equilibrio difícil de encontrar: es cómodo de escribir, escala bien, consume muy pocos recursos y está diseñado para aplicaciones en red y sistemas distribuidos. Empresas como Google lo usan en producción masiva por algo. Es más rápido que Python y JavaScript, y aunque no llega a Rust o C++, la diferencia en experiencia de desarrollo es abismal.

Frameworks de Go

Go ya trae librerías nativas para crear servidores sin necesidad de un framework externo, pero herramientas como Gin, Echo, Fiber o Chi simplifican tareas como el manejo de rutas, middlewares o TLS automático. Mi recomendación: empieza con Gin por su popularidad y documentación, aunque personalmente me gusta Chi por su simplicidad al instalarlo.

ORM: GORM

Para la comunicación con la base de datos, GORM es el ORM más popular del ecosistema Go. Permite definir structs en Go que se traducen directamente en tablas de PostgreSQL. También existen alternativas como SQLC o SQLX si prefieres escribir SQL puro y generarlo desde allí.

3. Frontend

En el frontend casi ningún proyecto usa JavaScript o TypeScript puro; prácticamente todos pasan por un framework. La pregunta real es cuál escoger según el caso.

React + Vite — paneles de control internos

Para dashboards y herramientas internas donde el SEO no importa, React con Vite es lo más rápido y sencillo. Genera una SPA (Single Page Application) donde todo el código es JavaScript: el tiempo de respuesta es mínimo y la separación entre frontend y backend es muy clara.

Next.js — cuando necesitas SEO o mayor versatilidad

Si el proyecto requiere que Google (o los agentes de IA) puedan indexar las páginas —un e-commerce, un blog, una landing— Next.js es la respuesta. Renderiza HTML en el servidor cuando es necesario, lo que mejora drásticamente el SEO. Es un poco más pesado que React + Vite, pero ofrece todos los métodos de renderizado disponibles hoy: SSR, SSG, ISR y Server Components.

🔵 Regla simple: ¿No necesitas SEO? → React + Vite. ¿Necesitas SEO o lógica de servidor antes de mostrar la página? → Next.js.

4. Mobile y Escritorio

React Native — iOS y Android con una sola base de código

El desarrollo nativo (Swift para iOS, Kotlin para Android) ofrece la mejor experiencia de usuario, pero mantener dos proyectos completamente separados tiene un costo alto. React Native permite crear aplicaciones para ambas plataformas con una sola base de código.

Flutter también es una opción válida, pero introduce Dart como lenguaje adicional, lo que aleja el stack de las tecnologías que ya conoces. React Native mantiene la coherencia con TypeScript/JavaScript del resto del proyecto.

Tauri — escritorio nativo con código web

Tauri es uno de los proyectos más interesantes del ecosistema. Permite tomar el código de tu aplicación web (React, Next.js) y empaquetarlo como una aplicación de escritorio nativa. La base está escrita en Rust, lo que la hace extremadamente rápida y ligera; por encima corre JavaScript que actúa como puente hacia las API del sistema operativo: notificaciones, acceso a archivos, atajos de teclado, actualizaciones automáticas.

La gran ventaja: si mejoras la aplicación web, la versión de escritorio hereda automáticamente esas mejoras. No hay que mantener dos proyectos separados.

5. Integración de IA

Las herramientas de IA no se conectan directamente a la base de datos. Lo habitual es crear aplicaciones intermedias que se comuniquen con tu backend existente. Hay dos patrones principales:

CLI propio — para agentes de terminal

Un CLI es una herramienta de consola que expone los comandos de tu sistema de forma accesible. Agentes de IA como Claude Code, Gemini CLI u Open Code pueden ejecutar comandos de terminal, lo que significa que si tu CLI permite consultar usuarios, crear proyectos o modificar datos, el agente puede hacerlo sin que tú intervengas.

Combinado con un "skill" (un prompt grande guardado que documenta cómo usar el CLI), el agente sabe exactamente qué comandos existen y cómo ejecutarlos. Esta es la tendencia del momento en entornos de desarrollo asistidos por IA.

MCP — para chats de IA sin acceso al terminal

Cuando el usuario interactúa desde un chat de IA (Claude Desktop, ChatGPT) y no puede instalar herramientas de consola, el MCP (Model Context Protocol) es la solución. Básicamente es una API encima de tu API: expone las operaciones disponibles en un formato que los modelos de IA entienden, incluyendo documentación sobre qué hace cada función y cómo enviar las peticiones.

Servicios como Google Calendar, Supabase o Stripe ya tienen sus propios MCPs disponibles. Los MCPs se pueden crear en cualquier lenguaje, aunque TypeScript y Python son los más comunes. Go también funciona muy bien para esto.

Modelos que uso

Para chat y escritura de código uso principalmente Claude y ChatGPT. Para trabajo en el terminal, Claude Code con el modelo Opus es el que mejores resultados me da, aunque el costo es mayor. GPT Codex también es una alternativa sólida. Gemini destaca para investigación por su ventana de contexto grande.

6. Editor de código

Con agentes de IA que escriben la mayor parte del código, el editor se convierte principalmente en una herramienta de navegación y revisión. No tiene mucho sentido pagar una suscripción premium a un editor si ya pagas por un agente como Claude Code.

Hoy vuelvo a usar VS Code: con el plugin de Claude Code o Open Code ya tienes más que suficiente. GitHub Copilot en su plan gratuito añade autocompletado. Para los que buscan algo más rápido, Zed es un editor escrito en Rust (código nativo, no Electron) que abre proyectos grandes con mucha fluidez. VS Code tiene la ventaja de un ecosistema de plugins enorme: pull requests, integraciones con bases de datos, soporte para MCPs y multi-agente.

7. Despliegue y CI/CD

Para hosting uso principalmente AWS, Digital Ocean, Railway y servidores propios vía SSH. Cada uno tiene su CLI para automatizar el despliegue.

El flujo completo de CI/CD vive en GitHub, que ofrece tres piezas clave en una sola plataforma:

• GitHub Actions — ejecuta el build y el despliegue automáticamente con cada push al repositorio.
• GHCR (GitHub Container Registry) — aloja imágenes Docker de tu backend y otros servicios.
• Releases — almacena versiones de tu app de escritorio o CLI para que los usuarios descarguen directamente.

Con este flujo, hacer un push a la rama principal desencadena automáticamente: compilación del backend → imagen Docker → despliegue en la nube. Las apps de escritorio se publican en Releases y los usuarios reciben actualizaciones automáticas.

8. ¿Monorepo o repositorios separados?

Un monorepo tiene sentido cuando todos los proyectos comparten el mismo lenguaje y pueden reutilizar lógica: si el backend y el frontend están ambos en TypeScript, un monorepo permite compartir tipos, validaciones y utilidades.

Pero bajo este stack —Go en el backend, TypeScript en el frontend— los lenguajes son distintos, así que no hay lógica directamente compartible. La recomendación: mantén la lógica separada en carpetas independientes dentro de un mismo repo si quieres, pero despliega de forma independiente. Hay proyectos como TypeGo que generan tipos de TypeScript desde structs de Go si necesitas ese puente.

💡 Puedes tener una sola carpeta en GitHub con subcarpetas /backend, /frontend, /mobile sin que eso sea un "monorepo real". Lo importante es que cada parte se despliega de forma independiente.

Conclusión

Este stack no es el más rápido posible (Rust puro lo supera) ni el más sencillo (todo en TypeScript sería más fácil de empezar), pero ofrece un equilibrio real entre rendimiento, experiencia de desarrollo, escalabilidad y capacidad para trabajar en equipo.

La clave está en que cada herramienta tiene un rol claro: Go para la lógica de servidor, React/Next para la interfaz web, React Native para mobile, Tauri para escritorio, CLI/MCP para IA, y GitHub como eje del CI/CD. Una vez que conoces bien cada pieza, agregar nuevas funcionalidades —o incorporar a otro desarrollador— se vuelve sorprendentemente cómodo.

¿Cambiarías alguna de estas herramientas? Déjame tu opinión en los comentarios del video. Siempre estoy buscando opciones para mejorar el stack.