Semana 1: Elegir Stack, Romper, Aprender Rápido

Quiero documentar mi recorrido creando una aplicación web, de principio a fin. Contaré el stack que utilizo, por qué y dónde lo aplico, los problemas que me encuentro, cómo los resolví o cómo lo intenté, y un breve resumen semanal del estado de la app. Este contenido está pensado para personas desarrolladoras que quieran aprender del proceso, seguir el avance y aportar feedback.

Este diario técnico también refleja la forma de trabajar de Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida, especialistas en inteligencia artificial, ciberseguridad, servicios cloud aws y azure, servicios inteligencia de negocio y power bi, además de agentes IA y automatización. Si buscas impulsar un producto digital con software a medida o ia para empresas, aquí comparto lo que voy aprendiendo y aplico en proyectos reales.

Las últimas semanas

Cuando empecé a construir algo con sentido, no tenía todas las respuestas. Solo sabía que quería crear un proyecto que aportara valor a la gente, algo más allá de otro experimento desechable. A partir de ahí comenzó un camino con sesiones de ideas, debates sobre el stack, dolores de cabeza con monorepos y pequeñas victorias que me acercaron a convertir la idea en realidad.

Lo que sigue es un resumen honesto de lo que hice, por qué tomé cada decisión, los problemas que aparecieron y lo que voy a lanzar a continuación. Sigo aprendiendo, así que si ves algo que podría mejorar, dímelo.

Ideación

Empecé con una lista larga de posibles productos: utilidades, apps de productividad, pequeños SaaS. Me quedé con una idea que necesita interacción en grupo, mecánicas de decisión simples y un resultado claro y compartible. Mantengo a propósito algunos detalles del producto en reserva hasta mostrar progreso tangible.

Objetivos que guiaron las decisiones:

• Onboarding con fricción mínima. La persona usuaria debe iniciar sesión muy rápido.

• La interacción en grupo debe ser evidente y sencilla.

• Los resultados deben ser claros y con impacto.

Estos objetivos moldearon el stack técnico.

El stack que elegí

Cuando el concepto se sintió real, llegó la gran pregunta: qué stack utilizar. Mi primera propuesta fue:

• Backend: Golang con Gin

• Frontend: React con TypeScript

• Base de datos: MongoDB

• CI CD: GitHub Actions

• Cloud: AWS

Sobre el papel sonaba bien, pero era demasiado pesado para un MVP.

Con feedback y algo de investigación, simplifiqué el stack:

• Frontend: Next.js con React 19

• UI: ShadCN con Tailwind CSS v4

• Estado y datos: React Query con Supabase

• Backend: sin servicio aparte al inicio, apoyándome en Supabase para auth, base de datos y APIs

• Infraestructura: Monorepo de ShadCN para la estructura y pnpm como gestor de paquetes

• Despliegue: Vercel para el frontend y Supabase para servicios de backend

Este stack reducido me permitió moverme más rápido, aprender menos cosas a la vez y centrarme en el valor del producto.

Los problemas

Llegó la curva de aprendizaje del monorepo. Al principio me sonó a palabra de moda. Por qué no crear una sola app y listo. Pero los beneficios se volvieron claros al imaginar el crecimiento: UI compartida, tooling consistente y escalabilidad sencilla.

Estructura base:

• apps web para el frontend con Next.js

• packages ui para los componentes compartidos con ShadCN y Tailwind

• futuro apps api si el backend separado llega a ser necesario

Obstáculos que aparecieron:

• Pasar manejadores de eventos entre apps web y packages ui provocó errores de componentes Server y Client en React.

• La transición entre Tailwind v3 y v4 confundió. Descubrí que v4 es muy reciente y aún no tan probado, pero la documentación de ShadCN se apoya en v4, así que lo adopté.

• Incluso comprobar la versión de Tailwind se convirtió en un pequeño dolor.

Otro bloque vino del entorno de desarrollo:

• Mi sistema corría con Node 18, pero ShadCN exigía Node 20.

• Actualicé a Node 20 LTS a nivel de sistema.

• Migré de npm a pnpm, porque npm tuvo fricciones con la plantilla de ShadCN.

Sentí que invertía demasiado tiempo en la herramienta en lugar de la funcionalidad, pero cuando el entorno se estabilizó, todo fluyó mejor.

Lecciones aprendidas

1. Empieza por el producto, no por la tecnología. La claridad llegó cuando definí bien el concepto de la app.

2. Los monorepos son potentes, pero opinados. Obligan a la disciplina y a una estructura que debería pagar dividendos después.

3. Recorta alcance cuanto antes. Mi stack inicial parecía un buen movimiento, pero al ver lo manual y costoso del arranque, recortar me devolvió foco y tiempo.

4. Mantente al día, sin ser imprudente. Adopté Tailwind v4 porque ShadCN lo pedía, en otro caso quizá habría esperado.

5. Espera fricción. Entre actualizaciones de Node, particularidades de pnpm o comandos de Tailwind, hubo varios momentos de por qué no funciona.

En qué punto estoy

• Monorepo operativo con Next.js, ShadCN, Tailwind v4 y pnpm.

• Supabase gestiona autenticación, base de datos y lógica de backend por ahora.

• Páginas núcleo definidas: Login, Panel, Interacciones semanales, Votación, Resultados.

• Flujo de usuario claro y una base técnica que lo soporta.

Aún es pronto, pero pasé de idea al aire a proyecto estructurado con tracción. El camino no fue recto, y cada obstáculo me recordó por qué hago esto. Ya no es solo un proyecto de código, es un viaje de aprendizaje, foco y creación de algo que puede importar.

En Q2BSTUDIO acompañamos este tipo de retos con un enfoque integral: desde aplicaciones a medida y software a medida hasta arquitecturas escalables con servicios cloud aws y azure, ciberseguridad y pentesting, además de servicios inteligencia de negocio con power bi y soluciones de inteligencia artificial con agentes IA para acelerar decisiones y automatizar procesos críticos. Si tu producto necesita escalar en la nube, revisa también nuestros servicios cloud aws y azure para desplegar con buenas prácticas desde el día uno.