De Primer Commit a Producto en Vivo en 48 Horas

21 de noviembre de 2025, 9:14 AM

Ahí fue cuando hicimos el primer commit. Un proyecto vacío. Un lienzo en blanco. Para la medianoche del 23 de noviembre, teníamos un producto en vivo con un dominio personalizado, sirviendo a usuarios reales.

Esta no es una historia sobre recortar esquinas o lanzar software defectuoso. Se trata de lo que sucede cuando sabes exactamente lo que estás construyendo y te niegas a perder tiempo en cualquier otra cosa.

Lo que se lanzó en 48 horas

Esto fue lo que estuvo en vivo al final del segundo día:

Una interfaz de chat AI en tiempo real. No un envoltorio alrededor de un API. Un sistema de chat adecuado con gestión de sesiones, historial de mensajes y respuestas en streaming. Los usuarios podían tener conversaciones con agentes AI que realmente recordaban el contexto.

Un sistema de archivos virtual. Los usuarios podían crear carpetas, subir archivos, renombrarlos, organizarlos en espacios de trabajo. La AI podía leer y escribir en estos archivos durante las conversaciones. No una demo de juguete — un sistema de archivos real respaldado por MongoDB.

Espacios de trabajo con cambio de agente. Diferentes espacios de trabajo podían usar diferentes agentes AI con distintas capacidades. Un usuario podía tener un espacio de trabajo de codificación, un espacio de trabajo de escritura y un espacio de trabajo de investigación — cada uno con su propio contexto y archivos.

Autenticación de usuarios y sincronización. Conectado a nuestro sistema de autenticación a través de RabbitMQ. Los usuarios iniciaban sesión y sus datos estaban ahí. A través de dispositivos. Inmediatamente.

Generación de imágenes. La AI podía generar imágenes durante las conversaciones. No solo respuestas de texto — salida visual real.

Plantillas. Puntos de partida preconstruidos para que los usuarios no se enfrentaran a una pantalla en blanco en su primera visita.

Pipeline de despliegue. Dockerizado, desplegado, funcionando en un dominio personalizado con la configuración de entorno adecuada.

Las decisiones que lo hicieron posible

Una velocidad así no proviene de trabajar 48 horas seguidas (aunque hubo bastante de eso). Proviene de las decisiones que tomas antes de escribir la primera línea de código.

Decisión 1: MongoDB sobre Mongoose. Comenzamos con Mongoose durante unas cuatro horas. Luego cambiamos a controladores de MongoDB en bruto. Mongoose añade una capa de validación de esquema que es útil para equipos grandes, pero es pura sobrecarga para un equipo pequeño que conoce su modelo de datos. Cuatro horas “perdidas” que nos ahorraron docenas de horas en las semanas siguientes.

Decisión 2: Construir el servidor y el cliente en un solo repositorio. Monorepo. Un docker-compose.yml. Un comando de despliegue. Sin coordinación entre repositorios. Sin “la API está desplegada pero el frontend no.” Cuando te mueves rápido, reducir el número de cosas que pueden desincronizarse es más importante que la pureza organizacional.

Decisión 3: Desplegar en producción el día dos, no el día veinte. Desplegamos antes de estar “listos.” El dominio estaba configurado, SSL estaba configurado, las variables de entorno estaban en su lugar — todo antes de que la mitad de las características estuvieran construidas. ¿Por qué? Porque desplegar es la parte que te sorprende. Es mejor descubrir esas sorpresas el día dos con tres características que el día veinte con treinta.

Lo que no construimos

Igualmente importante que lo que lanzamos es lo que deliberadamente dejamos fuera:

• Sin panel de administración. Usamos MongoDB Compass directamente.
• Sin sistema de diseño personalizado. Usamos valores predeterminados limpios e iteramos después.
• Sin analíticas. Observamos los registros del servidor.
• Sin pruebas automatizadas. (Eso llegó el día tres.)
• Sin documentación. El código era la documentación.

Cada uno de estos habría sido lo “responsable” a construir. Cada uno nos habría costado un día. Y ninguno de ellos nos habría enseñado lo que aprendimos al poner el producto frente a usuarios reales el día dos.

La lección

Hay una versión de esta historia donde pasamos dos semanas en diagramas de arquitectura. Donde debatimos esquemas de base de datos en un Google Doc. Donde configuramos un pipeline de CI/CD adecuado antes de escribir cualquier código de aplicación.

Esa versión de la historia termina con un plan hermoso y sin producto.

La versión que realmente sucedió terminó con un producto funcional y una larga lista de cosas por mejorar. Tomaremos ese intercambio cada vez.

Cuarenta y ocho horas. Primer commit a producto en vivo. No porque seamos genios. Porque tomamos decisiones rápido, lanzamos más rápido y arreglamos cosas en producción como lo hace todo el mundo — pero pocos lo admiten.

El producto que ves hoy, 84 días y 632 commits después, comenzó justo ahí. En 48 horas.