Construir un SaaS sin fondos: lo que aprendí haciendo Magenta
Sin inversión externa, sin equipo. Bootstrappeando con el cashflow de mi agencia mientras construía el producto en paralelo. Esto es lo que aprendí.
Cuando empecé a construir Magenta, tenía cero financiamiento externo y cero empleados de ingeniería. Tenía algo mejor: Demosle, mi agencia de marketing con clientes pagando, que me daba el oxígeno financiero para apostar sin morirme en el intento.
Eso es bootstrapping real. No drama de supervivencia — una apuesta calculada, construida en paralelo a un negocio que ya funcionaba.
Y aun así, cambia completamente cómo tomas decisiones de producto.
La trampa del perfeccionismo temprano
La mayoría de los builders que conozco —yo incluido en mis primeros proyectos— caen en la misma trampa: construir demasiado antes de vender.
El razonamiento es lógico: "Si el producto no está listo, no puedo mostrar algo bueno." El problema es que "listo" es una meta que se mueve. Siempre hay algo más que agregar antes de lanzar.
Con Magenta rompí ese patrón de forma forzada: vendí el producto antes de terminarlo. Tuve clientes pagando mientras aún estaba construyendo funcionalidades core.
Eso duele. Pero también es lo que te hace enfocarte en lo correcto.
Qué significa "construir lo mínimo" en serio
No significa hacer algo malo. Significa tener muy claro qué problema único resuelves en el día 1, y no construir nada más hasta que eso funcione perfectamente.
Para Magenta, el problema central era: los leads llegan por WhatsApp, se pierden, o nadie los califica bien. El agente tenía que recibir ese lead, hacerle preguntas de calificación, y pasarle al vendedor correcto con un resumen.
Eso, y nada más, fue lo primero que construí. Sin dashboard. Sin analytics. Sin integraciones complejas.
El dashboard vino después, cuando los primeros clientes lo pedían. El seguimiento automático, la atribución de campañas, el pipeline — todo eso llegó después, guiado por lo que los clientes reales necesitaban. Hoy Magenta hace bastante más que ese MVP, pero cada feature tiene un cliente detrás que la pidió.
El stack del día 1 vs. lo que construyes después
Cuando eres el único developer, cada tecnología que agregas es deuda que pagas en tiempo de mantenimiento.
Empecé con un stack que conozco bien y que puedo debuggear rápido: Next.js + Express + PostgreSQL + Prisma. Sin microservicios. Sin arquitecturas event-driven. Una base de datos, un backend monolítico, un frontend.
Pero hay una parte de la historia que esa versión no cuenta completa: con el tiempo construí una infraestructura AI propia — un core con orquestación de agentes, multi-modelo, RAG, herramientas dinámicas, multi-tenant. No usé LangChain ni ningún framework de terceros. Lo construí desde cero porque ninguno de los que existían se adaptaba a lo que necesitaba en producción real.
Eso no contradice el principio del stack simple — lo confirma. El día 1, lo mínimo. Después, construyes lo que el producto necesita y que nadie más te puede dar.
Vender es parte del producto
Lo que más me costó entender fue que las ventas no son algo que haces después de construir. Son parte del loop de aprendizaje.
Cada conversación con un potencial cliente me dice más sobre el producto que una semana de trabajo en código. Me dice qué le duele, qué palabras usa para describir el problema, qué objeciones tiene, qué precio le parece razonable.
Esa información va directo al producto. Cuando ves que un tipo de cliente se repite — el mismo rubro, los mismos problemas, el mismo lenguaje — construyes primero lo que ese cliente necesita. Las primeras iteraciones de Magenta las dictaron clientes de servicios y retail; el producto de hoy refleja eso.
El número que importa en las primeras semanas
No es usuarios. No es sesiones. No es MRR.
Es: ¿cuántas conversaciones de ventas tuve esta semana, y cuántas de ellas avanzaron?
Eso es lo único que te dice si vas en la dirección correcta. Todo lo demás es vanidad hasta que tienes 10 clientes pagando.
Lo que haría distinto
Vendería antes todavía. Literalmente antes de escribir la primera línea de código.
Un mock, una demo grabada, una landing con un botón de "quiero ser beta tester". Si no puedes conseguir 5 personas dispuestas a probar algo que no existe, probablemente tu hipótesis de producto está mal.
El código es lo más fácil de cambiar. Las hipótesis de negocio son lo más caro de cambiar tarde.
Si estás construyendo algo y quieres charlar sobre el proceso, escríbeme. No tengo todas las respuestas, pero sí algunas cicatrices útiles.