Construir no es vender

A un programador se le ocurre una idea y lo primero que abre es el editor. Antes de escribir una sola línea ya tiene decidido el stack, el nombre, hasta el dominio que va a comprar. Lo he hecho yo mismo muchas veces. Y el problema no es la idea ni el código: el problema es que se nos olvida preguntar quién va a usar eso, dónde está esa gente y cómo se va a enterar de que existe.

Los programadores estamos siempre enfocados en la tecnología: qué inventar, qué app sacar, qué SaaS montar, qué web lanzar. Pensamos muy poco en quién va a usar de verdad lo que hacemos. Y ahí está la clave de todo: no basta con hacer algo, hace falta que se vea. De nada sirve un SaaS excelente si nadie sabe que existe.

Construir es la parte cómoda#

Construir es agradable porque tiene recompensa inmediata: escribes una función, funciona, la ves correr. Es medible, depende solo de ti, y el compilador no te dice que no te interesa lo que has hecho, como sí puede decirte un cliente. Vender es justo lo contrario: incierto, lento, y te expone a que te ignoren, que es mucho más incómodo que un error de sintaxis.

Elegir construir antes que vender no es pereza, es huir de lo que da miedo. Y lo entiendo, porque a mí también me pasaba: prefería sumar una función más al producto que mandar un mensaje a un desconocido preguntándole si le serviría de algo.

El orden que aprendes a la fuerza#

Con el tiempo te das cuenta de que programar cuesta tiempo, y el tiempo es el recurso que de verdad no recuperas. Así que mejor invertirlo en cosas que sí o sí te van a dar dinero, o en las que estés dispuesto a meter esfuerzo publicitando de verdad, no solo publicando y esperando.

Una vez alguien me dijo algo que se me quedó grabado: primero véndelo, luego hazlo. Suena raro para quien viene de programar primero y preguntar después, pero es exactamente cómo funciona el mundo B2B: primero se busca la necesidad real de una empresa, se confirma que van a pagar por resolverla, y solo entonces se construye la solución. Nadie levanta el producto a ciegas y sale a ver si alguien lo quiere. Se pregunta antes de escribir el primer commit.

Eso cambia el orden de todo. En vez de "tengo una idea, voy a construirla y luego veré a quién le interesa", pasa a ser "hay alguien con un problema y dinero para resolverlo, y ahora construyo justo eso". El código deja de ser una apuesta y pasa a ser la respuesta a algo que ya sabes que tiene demanda.

Una idea que no se distribuye no existe#

Puedes tener el producto mejor hecho del mercado, y si nadie sabe que existe, es como si no existiera. Un producto mediocre con buena distribución le gana casi siempre, en resultados reales, a un producto excelente que nadie conoce. No es lo que a un programador le gustaría oír, pero es lo que pasa: dos años después, el que sigue en pie no es el que mejor código tenía, es el que más gente supo que existía.

Lo he visto en lo mío también: proyectos con buen código y cero usuarios porque nunca les dediqué tiempo a que se supieran. La parte de contarle a la gente que algo existe pesa tanto como la de construirlo, y durante mucho tiempo yo le dediqué cero horas a esa parte, convencido de que "si es bueno, se sabrá solo". No se sabe solo. Nunca se sabe solo.

Qué haría distinto#

Si empezara hoy de cero, invertiría primero el tiempo en confirmar que alguien va a pagar por lo que quiero construir, antes de tocar el editor. Buscaría la necesidad primero, hablaría con quien la tiene, y solo después me pondría a programar la solución concreta a ese problema concreto, no una versión genérica que espero que le sirva a cualquiera.

Eso es lo que me habría ahorrado más tiempo que cualquier otra decisión técnica que haya tomado: no una arquitectura mejor, no un framework distinto, sino haber preguntado antes de construir. Construir sigue siendo la parte que más me gusta. Pero ya sé que no sirve de nada si nadie se entera de que lo construí.