Construir nunca fue el cuello de botella, pero hacía otros tres trabajos (2026)

Tres tarjetas apiladas con los subproductos que eliminó construir barato: el filtro de ideas, la señal de confianza y la comprensión, cada uno junto a un hilo de Reddit de los más votados

La mayoría de las semanas leo los hilos más destacados de r/SaaS y r/startups. Normalmente son un cajón de sastre: un lanzamiento, un análisis de bajas, los primeros 9 dólares de alguien. Esta semana no. Tres hilos distintos, desde tres puntos de vista completamente diferentes, resultaron estar describiendo lo mismo sin que ninguno se diera cuenta.

Un constructor publicó que puede lanzar cualquier cosa y no encuentra ni una idea que merezca lanzarse. Una persona empleada en una empresa publicó que, cuando un proveedor presume de haber construido algo en un fin de semana, lo que oye es una advertencia. Y un consultor cuyo negocio consiste ahora en rescatar productos hechos con vibe coding contó cómo vio a un fundador con ochenta clientes de pago abrir su propia app y navegar por ella para descubrir qué pasaba cuando alguien cancelaba a mitad de mes.

Leídos por separado, son un problema de ideas, un problema de marketing y un problema de calidad. Leídos juntos, son un solo problema, y no es el que concluyeron las secciones de comentarios.

Los tres hilos

Esto es lo que dijo realmente cada uno, antes de que yo añada ninguna interpretación.

Hilo	Escrito por	Puntos	Comentarios
«Estoy harto de los fundadores de "lo hice en un fin de semana con IA"»	Un empleado de un comprador	306	102
«Puedo construir casi cualquier cosa. No encuentro una sola idea de SaaS que valga la pena»	Un constructor sólido	129	200
«Puedo construir cualquier cosa. No tengo ni idea de cómo hacer que a la gente le importe»	Un fundador que lanzó y no tuvo eco	84	108
«El mayor problema del vibe coding no es la seguridad»	Un consultor de rescates	81	51

Dos de ellos son la misma frase tecleada por dos personas distintas en dos subreddits distintos en dos días distintos: puedo construir cualquier cosa. Nadie lo discutió en ninguno de los dos hilos. El desacuerdo era solo sobre lo que viene después, y los comentarios principales se dividieron limpiamente entre «tienes un problema de ideas» y «tienes un problema de distribución», con un tercer grupo recurrente que insistía en que no, en realidad construir sigue siendo lo difícil y quien diga lo contrario lo hace mal.

Los tres grupos describen un síntoma. Lo que comparten es más útil.

Qué se eliminó realmente

Construir software era lento y caro. Todo el mundo está de acuerdo en que eso era malo, y en general lo era. Pero la lentitud hacía tres trabajos además de producir el software, y los hacía de forma invisible, gratis, lo quisieras o no.

Filtraba tus ideas. Señalaba tu madurez a los compradores. Y te enseñaba qué hacía tu propio producto.

La IA eliminó el coste. No sustituyó los tres subproductos. Esa es toda la forma de las quejas de esta semana, y es por lo que los consejos de los comentarios siguen sin acertar: no puedes arreglar un subproducto que falta esforzándote más en lo que antes lo producía.

Subproducto uno: el filtro de ideas

Cuando construir te costaba seis meses o noventa mil dólares, no podías tener treinta ideas. El coste hacía la selección por ti. Elegías la que podías defender ante ti mismo a las dos de la madrugada, y el puro peso del compromiso forzaba un nivel de escrutinio que parecía criterio pero era sobre todo miedo.

Si quitas el coste, desaparece con él la función que obligaba a elegir. El constructor de ese hilo describió su ciclo con precisión: hacer una lluvia de ideas, dar con algo ingenioso, descubrir que diez empresas ya lo hacen o que nadie lo busca, construir una versión rápida, darse cuenta de que no entiende en absoluto a los usuarios, y repetir. Llamó al resultado un cementerio de cosas ingeniosas a medio construir. Lo notable es que él mismo lo diagnosticó bien: escribió que inventa ideas desde la silla en lugar de robarlas de un problema dentro del cual vive.

Es exactamente así, y merece la pena precisar por qué. Construir es la parte cómoda. Tiene una definición de terminado, produce un avance visible y nadie te dice que no mientras lo haces. Llegaron doscientos comentarios para decirle que hablara con clientes, y él ya lo sabía. La razón por la que los fundadores se esconden en la construcción no es la ignorancia. Es que construir es la única parte del trabajo que recompensa el esfuerzo con resultados de forma fiable, y cuando no cuesta nada puedes esconderte ahí indefinidamente.

El comentario más afilado del hilo replanteó la búsqueda por completo. No hagas un inventario de problemas, decía, haz un inventario de molestias. No «qué falta», sino qué tolera la gente en silencio y nunca menciona, porque no le parece un problema real. Los veinte minutos de angustia antes de una revisión con un cliente. La hoja de cálculo que alguien rehace cada lunes. Eso nunca aparece en un análisis competitivo, porque técnicamente no hay nada roto. Ahí es donde vive de verdad la disposición a pagar.

Subproducto dos: la señal de confianza

Este es el que menos preparados encuentra a los fundadores, porque no desapareció: se invirtió.

Los compradores nunca tuvieron forma de inspeccionar tu ingeniería. Lo que tenían era un indicador indirecto: el software a medio hacer parecía a medio hacer. Bordes sin pulir, estados que faltaban, una página de ajustes fea: todo eso indicaba aproximadamente cuánto trabajo quedaba, y los compradores lo leían con soltura sin llegar a formular que lo estaban haciendo. El pulido era el recibo de haber sobrevivido a los casos límite.

Ahora el envoltorio con aspecto de terminado llega el primer día. El indicador se rompió, y el mercado hizo lo que hacen los mercados cuando se rompe una señal: la sustituyó por otra más tosca. El post de 306 puntos es esa sustitución dicha en voz alta. Su autor, una persona empleada a la que le dejan herramientas sobre la mesa con la orden de incorporarlas a su trabajo, enumeró lo que su empresa paga realmente —que sigas ahí en el sexto mes, que no pierdas nuestros datos, que la cosa haga lo mismo cada vez— y luego soltó la frase en la que todo el hilo estuvo de acuerdo: deja de presumir de velocidad, porque para quienes te pagan suena a advertencia.

La advertencia honesta

Una gran parte de los comentarios acusó al post de ser cebo de interacción generado con IA, y le pidieron al autor que nombrara un solo producto real que le hubiera fallado. Puede que tengan razón. Pero eso no es motivo para descartar el hilo: es el mismo fenómeno una capa más arriba. La acusación cala porque un resultado con aspecto pulido ya no certifica esfuerzo en ninguna parte, tampoco en un post de Reddit. El indicador de confianza se rompió a la vez para el software y para la prosa, por la misma razón.

La consecuencia práctica es que la velocidad ha dejado de ser un activo de marketing y se ha convertido, sin hacer ruido, en un pasivo que tienes que compensar. Nada de tu texto de lanzamiento debería empezar por lo rápido que lo construiste. Lo que buscan ahora los compradores son pruebas de duración y de consecuencias: cuánto tiempo llevas funcionando, qué pasa cuando algo se rompe, quién responde, si sus datos sobreviven a una mala versión. Un fundador del hilo propuso una métrica que merece la pena copiar: cuenta cuántas conversaciones de soporte son el mismo problema que vuelve por segunda vez. No el volumen de tickets. Las repeticiones. Es una lectura implacable de qué partes de tu producto se sostienen con cinta adhesiva, y le da igual lo rápido que las lanzaras.

Subproducto tres: la comprensión

El hilo del consultor de rescates es el más valioso de los cuatro y el que menos atención recibió, que es lo habitual.

La historia: un fundador llevó un producto de reservas que había hecho con vibe coding en unos cuantos fines de semana. Era realmente bueno, pulido, con unos ochenta clientes de pago. Entonces un cliente preguntó qué pasa con la parte no usada de un plan si cancelas a mitad de mes, y el fundador abrió su propio producto y navegó por él para averiguarlo. No le dio vergüenza. Para él, así es simplemente como se descubre qué hace tu producto.

La explicación del consultor de por qué esto es distinto de la deuda técnica es la parte que merece la pena llevarse: la deuda presupone que alguien puede leer los libros. Aquí, en cuanto un cliente discute una cifra, el fundador tiene que cambiar un comportamiento que nunca entendió, y ninguna refactorización cierra esa brecha porque la brecha nunca estuvo en el código. Los comentaristas coincidieron en llamarlo deuda de comprensión.

Conviene explicar el mecanismo con cuidado, porque no es «la IA escribe mal código». El código estaba bien. Lo que pasó es que se tomó una decisión y nadie supo que se estaba tomando una decisión. Alguien —algo— tenía que decidir qué hace una cancelación a mitad de ciclo con un saldo prorrateado. El modelo decidió, con seguridad, de una forma que parecía plausible en pantalla, y el fundador nunca vio un punto de decisión. Como dijo el consultor en un comentario posterior: escribe primero las decisiones, o el modelo las tomará por ti.

Su diagnóstico es lo más accionable de los cuatro hilos, y lleva unos veinte minutos:

La prueba de las cinco preguntas

Escribe las cinco preguntas más difíciles que un cliente podría hacer sobre cómo se comporta tu producto. Respóndelas sin abrir la app. Las que no puedas responder son las partes del negocio que todavía no son tuyas.

Un detalle más del mismo hilo, de alguien que ha hecho varios de estos rescates: en la facturación suele haber tres versiones de la verdad dando vueltas, lo que está en el código, lo que está en Stripe y lo que el fundador ha ido diciendo a la gente en los correos de soporte. Conseguir que esas tres coincidan es el rescate, la mayoría de las veces. El trabajo de código posterior es lo fácil.

Por qué los consejos sobre distribución siguen fallando

El fundador de r/startups —el producto funciona, a unos pocos usuarios les encanta, no tiene ni idea de cómo hacer que le importe a alguien— recibió 108 comentarios, y la mayoría decía lo mismo en tres palabras: busca veinte personas. Es un buen consejo y no le sirvió, y la razón la nombró un comentarista con una precisión poco habitual: la mayoría de los fundadores no sabe decir quiénes son esas veinte personas. No el sector, no el perfil. La situación concreta que hace que alguien necesite esto hoy y no el trimestre que viene.

La diferencia entre «gente de operaciones en empresas SaaS» y «gente de operaciones que acaba de contratar a su primer SDR y se ha dado cuenta de que no tiene proceso» es la diferencia entre un canal al que puedes ir a buscar en frío y una categoría en la que solo puedes anunciarte. Todo lo que viene después —el texto, el canal, el momento— es secundario.

También hubo una buena respuesta a la verdadera objeción del fundador, que era que publicar le parece actuar y lo hace mal. Dos comentaristas, por separado: deja de emitir y empieza a responder. Ve donde se habla del problema y responde preguntas, la mayoría sin nada que ver con tu producto. Responder no es subirse a un escenario. Y, por otro lado, pregunta al puñado de personas que ya usan lo que haces en qué hilo, foro, Slack o subreddit estaban en el momento en que el problema les molestó lo suficiente como para ponerse a buscar. Eso te da tres sitios reales en lugar de una estrategia de contenidos.

Recuperar los subproductos

Si el diagnóstico es que tres cosas que antes obtenías gratis ahora hay que comprarlas a propósito, el trabajo consiste en programar cada compra. En concreto:

Sustituye el filtro del coste por un filtro de evidencia. Elige un grupo de personas al que puedas llegar de verdad y reúne diez momentos recientes en los que pagaron por algo, esperaron algo o montaron una hoja de cálculo a su alrededor. Diez momentos concretos, con fecha y con nombres. Si no encuentras diez, esa es la respuesta.
Vende primero la versión manual. Ofrece el arreglo más pequeño, feo y hecho a mano antes de escribir software. Si nadie te da tiempo o dinero por la versión fea, un código mejor no la salvará. Es la única función que sigue obligándote a elegir, no cuesta nada ponerla en marcha y todavía te dice que no.
Escribe el comportamiento antes de construirlo. Una tabla corta —facturación, cancelación, reembolsos, permisos, recuperación de fallos— con el resultado previsto en cada fila y una comprobación ejecutable. No es documentación escrita a posteriori; es el conjunto de decisiones que, si no, el modelo tomará en silencio por ti.
Haz la prueba de las cinco preguntas con lo que ya has lanzado. Hoy, antes de que un cliente la haga por ti. Cada pregunta que no puedas responder de memoria es una decisión que no controlas.
Mide las conversaciones de soporte repetidas, no el volumen de tickets. Una tasa de repetición creciente es la señal honesta más temprana de que una parte de tu producto nunca se terminó del todo, por muy terminada que parezca.
Comunica duración, no velocidad. Disponibilidad, historial de incidentes, tiempos de respuesta, cuánto tiempo llevas funcionando, qué pasa con los datos al cancelar. Es la evidencia que usan ahora los compradores en lugar de la señal que se rompió, y es la única parte del discurso que un competidor no puede generar en un fin de semana.
Nombra el detonante, no el perfil. Escribe la frase que describe la situación concreta que hace que alguien necesite esto hoy. Si no puedes, ningún canal te salvará, porque el canal nunca fue el problema.

La lectura

Las secciones de comentarios pasaron la semana discutiendo si lo difícil es construir, idear o vender. Es una mala discusión, porque la respuesta no deja de cambiar y nunca fue la pregunta interesante. La pregunta interesante es qué estaba pagando un coste en silencio antes de desaparecer.

Seis meses de construcción te compraban antes una idea filtrada, un producto creíble y un modelo mental funcional de tu propio negocio. Pagabas por una cosa y recibías cuatro. Ahora no pagas por nada y recibes una, y las otras tres hay que adquirirlas a propósito, por parte de gente que en su mayoría no sabe que le faltan.

Esa es la verdadera habilidad del fundador en 2026. No el prompting, no la velocidad de lanzamiento: darse cuenta de cuáles de tus antiguos subproductos gratuitos han dejado de llegar, e ir a comprarlos antes de que un cliente descubra que nunca los tuviste.