Quince años construyendo software y cero ventas: el diagnóstico honesto

Llevo más de quince años construyendo software y nunca he vendido nada por mi cuenta.

Y antes de que alguien lo piense, no es falta de capacidad técnica: he construido cosas que corren en producción, con usuarios reales, con infraestructura que no se cae y que se levanta sola cuando algo falla. Lo que nunca hubo fue un solo peso entrando por algo que construí.

”El trabajo bueno se nota solo”

Esa frase me tuvo quieto una década.

Es el consuelo favorito de los ingenieros y es mentira, pero es una mentira cómoda, porque convierte la inacción en paciencia: si el trabajo habla solo, entonces no vender deja de ser un problema y pasa a ser una etapa, algo que va a ocurrir más adelante por su propio peso, y mientras tanto uno sigue haciendo lo único que sabe hacer bien, que es construir.

No se nota. Nunca se notó. Llevo quince años de evidencia.

El ejercicio incómodo

Hace unos días me senté a revisar por qué, y no a buscar culpables afuera, que es lo fácil y lo que había hecho siempre, porque el mercado, el momento y la falta de tiempo están siempre disponibles cuando uno necesita una explicación que no duela. Me senté a mirar el sistema completo.

La respuesta no estaba en el producto. Tampoco en el código.

Nunca construí la otra mitad, la parte donde alguien se entera de que eso existe y decide pagar.

Sé diseñar un sistema distribuido, sé dónde poner una cola, sé cómo aislar un fallo y sé revisar código que no escribí. No sabía escribir una oferta. Nunca había mandado un correo pidiendo algo. Nunca había publicado catorce días seguidos.

Dediqué quince años a la mitad técnica y cero horas a la mitad comercial, y después me sorprendí de que la segunda no funcionara. Dicho así suena ridículo, y es que lo es.

Lo que voy a hacer

Voy a tratarlo como trato cualquier sistema que no entiendo: construirlo en público, medirlo y publicar los números.

Durante los próximos catorce días voy a escribir todos los días sobre cómo trabajo con agentes de código, lo que uso de verdad y no lo que se ve bien en una demo: cómo administro el contexto cuando el proyecto crece, qué automatizo y qué no, dónde el agente no debe decidir, cómo reviso código que no escribí yo.

Con los errores incluidos, y sobre todo con los errores, porque de eso casi nadie escribe.

Al final voy a contar qué pasó, funcione o no. Si no funciona eso también es información, porque querría decir que el cuello de botella no era el producto ni el método sino la distribución, y que llevo quince años resolviendo el problema equivocado.

Por qué en español

Casi todo lo que se publica sobre agentes de IA son demostraciones de cinco minutos, donde alguien pide una app, el modelo la genera y vienen los aplausos.

Lo que casi no existe en español es el método para operarlos en serio: qué reglas escribir y por qué, qué se rompe cuando faltan, y cómo evitar que el agente modifique un test para que pase, que es el camino más corto al verde y el fallo más difícil de pillar en una revisión.

Eso es lo que voy a escribir.

Empiezo por lo más concreto que tengo

Mañana publico qué hay realmente dentro del CLAUDE.md con el que arranco cada proyecto. No la versión de ejemplo: el archivo, con un comentario por regla explicando por qué está ahí y qué se rompe sin ella.

Si lo quieres antes, te lo dejo gratis acá.

Y una pregunta, porque la respuesta me interesa de verdad: ¿cuál es la cosa que sabes hacer bien y nunca cobraste?