Construir es más barato que reunirse

El coste en tokens de construir una funcionalidad en producción ya es menor que el coste de la reunión donde se discute si hay que construirla.

Lo repito porque merece que lo leas despacio.

Es literalmente más barato construir la cosa y ver si funciona que convocar una reunión de 60 minutos para debatir si merece la pena construirla.

Piénsalo así. Una reunión de planificación con cuatro personas durante media hora: 4 salarios prorrateados, la preparación previa, el contexto perdido al volver al trabajo, las decisiones aplazadas “para la siguiente”. Fácilmente 100, 200 y hasta 300 euros en coste real (dependiendo de la empresa, clarooo!).

Un prototipo funcional construido con IA en 2 horas: 20 euros en tokens. Quizás menos.

No es una diferencia del 10%. Es un orden de magnitud. Y esa brecha se agranda cada trimestre.

Esto invierte por completo cómo deberías gestionar una organización de software.

Durante décadas, la lógica era simple: construir es caro, planificar es barato. Por eso invertíamos semanas en diseñar, debatir, aprobar. Cada hora de reunión “ahorraba” decenas de horas de desarrollo mal dirigido. Tenía sentido.

Ya no.

El coste del código ha caído a prácticamente cero. La capa de planificación se ha convertido en el cuello de botella porque la capa de construcción es esencialmente gratuita.

Y aquí viene lo que a muchos les cuesta aceptar: la respuesta racional es eliminar la planificación para todo lo que pueda probarse empíricamente.

No debatas si una funcionalidad va a funcionar.

Constrúyela en 2 horas. Mídela con un grupo de clientes. Decide si la matas o la mantienes.

Muchas de las cosas que hacemos hoy en Rebundle son así. Sin reuniones de priorización. Sin decks de 40 slides para justificar una feature. La velocidad de construcción es exponencial y la clave es que ni yo ni nadie sabe mas que el mercado. No hay mejor validación que salir y equivocarte.

Creo que lo más interesante no es la velocidad. Es la calidad de las decisiones.

Cada decisión está informada por un prototipo real, no por una presentación de PowerPoint y una opinión de alguien que “lleva muchos años en el sector”.

Antes: hipótesis, debate, consenso, aprobación, backlog, sprint, revisión. 8 semanas.

Ahora: construir, medir, decidir. 8 horas.

Pasamos de “move fast and break things” a “move fast and build everything”.

Y esto mata muchas cosas que dábamos por sagradas:

El roadmap trimestral. Si puedes construir y validar en un día, planificar a tres meses vista es una ficción. Es un ejercicio de confort organizacional, no de estrategia.

El product manager como guardián del backlog. Si el coste de probar es menor que el coste de priorizar, el rol cambia por completo. De decidir qué se construye a interpretar qué dicen los datos de lo que ya se construyó.

La reunión de kick-off. La reunión donde 8 personas alinean expectativas sobre algo que ninguna ha visto. Sustituida por un Loom de tres minutos mostrando el prototipo que ya existe.

El “no” preventivo. Ese “no lo hagamos porque probablemente no funcione” pierde todo su sentido cuando probar cuesta menos que argumentar.

No todo muere. Algunas cosas se vuelven más valiosas precisamente porque construir es gratis.

El criterio. Cuando puedes construir cualquier cosa, la pregunta deja de ser “¿podemos?” y pasa a ser “¿deberíamos?”. Saber qué merece existir es el nuevo superpoder.

La interpretación. Tienes 40 prototipos en producción generando datos. ¿Qué te dicen? ¿Qué patrón ves? La capacidad de leer señales en el ruido vale más que nunca.

La conversación con el cliente. No la reunión interna. La conversación real con quien usa tu producto. Esa siempre fue valiosa. Ahora es la única reunión que importa.

Hay una industria entera construida alrededor de la planificación del software. Frameworks de priorización. Herramientas de roadmap. Certificaciones de product management. Consultoras de transformación ágil.

Todo esto asumía que construir era el recurso escaso y planificar era el apalancamiento.

Esa asunción ha muerto.

Y las organizaciones que no lo entiendan van a seguir celebrando reuniones sobre lo que sus competidores ya lanzaron, midieron y decidieron.

La verdad es que esto me genera una tensión. Yo he sido de los que planifican. De los que hacen la reunión antes de empezar. De los que necesitan el plan antes de escribir la primera línea.

Nada que no haya sustituido el “AskUserQuestionTool” de Claude Code ;) (comentario friki)

Pero los datos no mienten. Y cuando construir cuesta menos que discutir, aferrarse a la planificación no es prudencia.

Es miedo.

¿…y en tu organización, cuántas reuniones de planificación podrían sustituirse por un prototipo de 2 horas?