Por qué construir ya no es lo único necesario (y probablemente nunca lo fue)

Hace un año tenía una meta en mente: usar los ingresos que tenía para crear un negocio.

Y mi primera idea no tenía nada que ver con software.

Busqué diferentes opciones y, después de algunos días de investigación, me decidí: invertiría en jabones artesanales.

Entonces apareció un problema.

Enviaba correos buscando proveedores y no me respondían.

Así que hice lo que probablemente haría cualquier desarrollador frente a un problema: construí algo.

Sin pensar todavía en convertirlo en un negocio de software, creé un agente de IA que respondía tu bandeja de entrada.

Y cuando funcionó me sentí muy bien.

De alguna manera, toda mi experiencia como desarrollador llegaba a ese momento. Había encontrado un problema y había sido capaz de construir una solución.

Solo había un pequeño inconveniente:

Probablemente no estaba resolviendo el problema correcto.

La herramienta murió más rápido de lo que se construyó

Un año después veo aquella experiencia de manera muy diferente.

La herramienta murió más rápido de lo que se construyó.

Y no porque fuera imposible desarrollarla, sino porque nunca tuve suficiente evidencia de que alguien realmente la necesitara y, sobre todo, de que alguien estuviera dispuesto a pagar por ella.

Si hubiera invertido parte de ese tiempo buscando usuarios cuando la herramienta todavía no existía, probablemente habría descubierto una de dos cosas:

1. Que no valía la pena construirla.
2. O que el problema real era otro.

En ambos casos habría aprendido algo antes de escribir cientos o miles de líneas de código.

Construir ya no es evidencia suficiente

Por eso, como desarrollador, ya no recomiendo simplemente construir software.

Construir sigue siendo increíble para aprender, mantener conocimientos y experimentar. Y hay productos cuya dificultad técnica sigue siendo enorme.

Pero poder construir algo ya no es evidencia suficiente de que vale la pena construirlo.

Y esto se vuelve todavía más evidente ahora que existen modelos capaces de generar un prototipo a partir de unos cuantos prompts. Todavía es caro, todavía cometen errores y todavía estamos lejos de que construir software complejo sea trivial.

Pero la dirección parece bastante clara:

Construir será cada vez más barato. Encontrar algo que alguien realmente quiera seguirá siendo difícil.

¿Qué haría diferente? Mi marco de validación

Si mañana quisiera lanzar un nuevo producto, mi primer objetivo no sería construir el producto.

Sería construir el experimento que me permita descubrir si el producto merece existir.

1. Empezaría con infraestructura mínima

Un dominio cuesta alrededor de 11 dólares y me permite tener una identidad propia para el proyecto. Un VPS sencillo puede costar alrededor de 5 dólares al mes y me da suficiente libertad para ejecutar pequeños experimentos sin comenzar acumulando suscripciones.

2. Escribiría un brief

Nada enorme. Probablemente una página.

• Nombre
• Segmento al que quiero llegar
• Problema que creo estar resolviendo
• Propuesta de valor
• Posibles funcionalidades
• Planes y precios

No porque crea que esas respuestas son correctas. Precisamente porque quiero tener por escrito qué estoy suponiendo.

3. Decidiría cómo voy a saber si estoy equivocado

• ¿Qué voy a medir?
• ¿Qué tendría que suceder para considerar que existe interés?
• ¿Cuál es la métrica que me dirá que voy en la dirección correcta?

4. Entonces sí construiría (pero no el producto)

Construiría una landing page, formularios, perfiles sociales o cualquier otro mecanismo que me permita poner la idea frente a personas reales.

• Haría publicidad.
• Hablaría con posibles usuarios.
• Probaría mensajes.
• Probaría precios.
• Y mediría.

Porque en esta etapa no estoy intentando demostrar que mi idea funciona.

Estoy intentando encontrar evidencia de que vale la pena seguir invirtiendo en ella.

Documentaría absolutamente todo

• Qué cambié.
• Por qué lo cambié.
• Cuánto gasté.
• Cuántas personas llegaron.
• Cuántas preguntaron.
• Cuántas dejaron sus datos.
• Cuántas estuvieron dispuestas a pagar.
• Qué mensajes funcionaron.
• Cuáles no.
• Qué supuse que ocurriría y qué ocurrió realmente.

Probablemente cada dato aislado diga muy poco.

Pero después de semanas o meses empiezas a tener algo que al principio no tenías: historia.

Y esa historia permite tomar mejores decisiones.

La IA como segundo cerebro del proyecto

Aquí también usaría IA.

No para que tome las decisiones por mí, sino para ayudarme a analizar todo ese contexto.

Con suficiente documentación puedes crear un proyecto, darle ese historial y empezar a hacer preguntas:

• ¿Qué patrones aparecen?
• ¿Qué hipótesis hemos cambiado?
• ¿Qué decisiones contradicen nuestros propios datos?
• ¿Qué estamos ignorando?

La IA deja entonces de ser solamente una herramienta para generar código y empieza a convertirse en una especie de segundo cerebro del proyecto.

Y definiría cómo muere

Probablemente este sea uno de los puntos que más habría necesitado entender hace un año.

Antes de comenzar definiría:

• Cuánto dinero estoy dispuesto a perder.
• Cuánto tiempo estoy dispuesto a invertir.
• Qué resultados necesito observar.
• Y, sobre todo, bajo qué condiciones voy a cerrar el proyecto.

Porque llegará ese momento.

Ese en el que piensas: “Si cambio esto, ahora sí va a funcionar.”

Después será otra feature. Otro precio. Otro diseño. Otra campaña. Otro segmento.

Siempre habrá una razón para intentarlo una vez más.

Y cuando llevas meses construyendo algo, dejarlo morir se vuelve cada vez más difícil.

Por eso las condiciones de muerte deberían existir antes de enamorarte de la solución.

¿Y después de hacer todo esto el negocio funcionará?

No.

Nada de esto garantiza que funcione.

De hecho, podrías hacer todo correctamente y descubrir que nadie quiere lo que estás intentando vender.

Pero ese también sería un resultado.

Porque el objetivo de todo este proceso todavía no es demostrar que tienes un negocio.

Es conseguir suficiente evidencia para decidir si vale la pena construirlo.

Y si decides saltarte todo esto y comenzar directamente por el producto, probablemente tendrás que aprender las mismas cosas después.

Solo que ahora lo harás mientras arreglas bugs. Mientras mantienes infraestructura. Mientras cada cambio cuesta más. Mientras intentas descubrir por qué no llegan usuarios. Y mientras tienes delante algo que te costó tanto construir que ya no quieres abandonar.

---

Hace un año encontré un problema y construí una solución.

Hoy haría algo diferente.

Primero construiría el experimento. Después buscaría la evidencia. Y solo entonces decidiría si vale la pena construir el producto.

Este es el marco de trabajo al que he llegado después de equivocarme construyendo.

¿Cuál es el tuyo?

¿Sigues creyendo que construir primero la solución es indispensable para salir al mercado?

---