CREA.MBASobre-ingeniería, no medir, lanzar sin email, cambiar de stack… los 7 errores que matan al primer SaaS y cómo evitarlos.
Cada builder novato comete los mismos 5-6 errores. No es falta de talento: es falta de calibración. Y la mayoría de esos errores no se ven hasta que ya te has comido 2 meses construyendo algo que no encaja con la realidad.
Esta guía es la lista. Si te ves en alguno, no es vergüenza: es información.
Cómo se ve: arquitectura microservicios, Kubernetes, message queues, GraphQL Federation, multi-region, antes de tener un solo cliente.
Por qué pasa: leíste un blog post de Stripe / Netflix / Airbnb y crees que necesitas lo mismo en tu MVP de 0 usuarios.
El coste: pasas 3 meses construyendo infraestructura para escalar a millones de usuarios. Lanzas tarde. No tienes ninguno.
Cómo evitarlo: monolito hasta los primeros 1000 usuarios. PostgreSQL hasta donde aguante (y aguanta mucho). Una sola región. Una sola DB.
Cómo se ve: tienes la app en producción, no sabes cuántas visitas tiene, ni qué páginas miran, ni dónde se atascan en el funnel.
Por qué pasa: "ya pondré analytics más adelante". O "no quiero contaminar el código".
El coste: vas a ciegas. Iteras basándote en intuición. Decides feature roadmap por sentimiento. La mitad de tus decisiones serían distintas si tuvieras 5 datos.
Cómo evitarlo: 30 minutos para meter Plausible/Umami/Clarity. Mira los datos cada lunes. Aunque solo sea para ver "¿alguien entró este fin de semana?".
Cómo se ve: pasas 3 semanas perfeccionando la landing, lanzas, y solo se entera tu hermano.
Por qué pasa: porque crees que "el producto se vende solo si es bueno". O porque te da vergüenza enviar email.
El coste: lanzamiento muerto. Y peor: te convences de que "el mercado no quería esto" cuando en realidad nadie supo.
Cómo evitarlo: lista la construyes desde el día 1, antes que el producto. El día del lanzamiento, email obligatorio. Aunque sean 30 personas. Aunque te dé pudor. Es el día más importante.
Cómo se ve: empiezas con Next.js, en la semana 4 te frustras con un bug, ves un tweet de "Astro es mejor", abandonas Next y empiezas Astro. Tres semanas después, otro tweet sobre SvelteKit.
Por qué pasa: shiny object syndrome. Cualquier framework te parece mejor que el que tienes debugueando.
El coste: meses perdidos cambiando de stack. Cero progreso real.
Cómo evitarlo: regla simple → no cambias de stack hasta tener 100 usuarios reales. A esa altura, ya tendrás datos para decidir si la fricción es del stack o tuya.
Cómo se ve: lanzas la feature un viernes a las 22:00, "ya pruebo el lunes". El lunes el formulario tiene un bug, 5 usuarios afectados, ya se han ido.
Por qué pasa: prisa. Cansancio. La idea romántica de "muevete rápido y rompe cosas".
El coste: pierdes confianza de los pocos usuarios que tienes. Es 10x más fácil retener que captar.
Cómo evitarlo: día de QA fijo. En el sprint de 5 días, el viernes es para probar. No para empujar features.
Cómo se ve: 6 meses construyendo en silencio. Cuando lanzas, te das cuenta de que el problema que resuelves no es el problema que tu ICP tiene.
Por qué pasa: miedo. "No quiero enseñarlo hasta que esté bien".
El coste: construyes algo que nadie quiere. Te das cuenta cuando ya no hay vuelta atrás.
Cómo evitarlo: hablas con 10 personas del ICP antes de escribir una línea de código. Y otras 10 con el MVP feo, antes de pulirlo.
Cómo se ve: añades dark mode, analytics propios, sistema de referidos, plan anual con descuento, integraciones con Slack… cuando nadie te lo ha pedido.
Por qué pasa: confundes "feature" con "valor". Y construir features se siente productivo.
El coste: producto saturado, código complejo, mantenimiento alto, valor cero.
Cómo evitarlo: cada feature debe responder a "¿qué cliente me lo pidió y qué problema resuelve?". Si no hay respuesta clara, no se construye.
Los 7 errores tienen una raíz: construir antes de validar. Validar es incómodo (hablas con gente, recibes "no") y construir se siente bien (avanzas, ves líneas).
Pero solo el primero genera valor. El segundo genera código.
Si te has visto en 2-3 de estos errores, eres un builder normal. Lo malo no es cometerlos: es no aprender de ellos.
El indie hacker que crece es el que cada 30 días repasa esta lista, identifica en cuál cayó este mes, y ajusta. No es genio: es disciplinado.
Y si no te ves en ninguno, sigue mirando. Probablemente es el #6.
Suscríbete para más tutoriales y tips sobre crear productos con IA