En 2014 lancé VipKing, una app para entrar en discotecas de Barcelona. Después sacamos un trozo como Pictus. Ninguna me hizo rico. Ambas me enseñaron cosas que diez años como ingeniero no me habían enseñado.
Lo menciono porque paso mucho tiempo en salas donde un fundador y un líder técnico hablan sin escucharse, y la razón por la que suelo ver la brecha es que he estado equivocado desde ambas sillas.
Error uno: optimicé lo que me gustaba
Soy ingeniero. Así que construí. La arquitectura era limpia, las animaciones fluidas, el proceso de release ordenado. Pasé semanas en cosas que ningún usuario vería nunca, y me sentía productivo todo el tiempo, porque construir es medible y vender no.
Mientras tanto la pregunta real — ¿darían entrada gratis a desconocidos los dueños de discotecas? — se quedó sin probar durante meses. Se podía responder en dos semanas con una hoja de cálculo y diez llamadas.
Este es el error más común que veo en fundadores técnicos, y nunca se ve como un error desde dentro. Se ve como progreso.
Error dos: confundí el producto con el negocio
La app funcionaba. Los usuarios la querían. Parecía traction. No lo era — traction era que los clubes renovaran, y renovaban por razones que casi nada tenían que ver con el software: relaciones, timing, si al promoter de ese mes le caíamos bien.
Estaba iterando mucho sobre una variable que no era la restricción. Si tu producto mejora y nada cambia, estás mejorando lo equivocado, y ninguna cantidad de rigor de ingeniería te salvará.
Error tres: traté el agotamiento del dinero como un problema de finanzas
Es un problema de velocidad de decisión. Cada semana gastada en algo que no reducía una incertidumbre real era una semana de runway gastada en nada. No pensaba en esos términos hasta que fue tarde.
Aprendí ese framing en los dos programas que hice ese año — Yuzz, la preaceleradora de Banco Santander, y NEXT, Powered by Google for Entrepreneurs. Lo que ambos inculcaban era incómodo: ¿qué tendría que ser verdad para que esto funcione, y cuál es la forma más barata de averiguarlo? He escrito por separado sobre lo que esos programas hicieron bien.
Cada semana que no reduce una incertidumbre es runway gastada en nada.
La lección que me costó una empresa aprender
Cómo cambió mi forma de trabajar
Cuando después me convertí en líder técnico de productos con usuarios reales — una app iOS con más de un millón de descargas — volví con tres hábitos que ningún trabajo de ingeniero me había enseñado.
- Pregunta qué pasa si nos equivocamos. Antes de estimar cualquier cosa. Si equivocarse es barato, lanza y averigua. Si es caro, ve más lento. La mayoría de equipos aplican el mismo rigor a ambos, lo que es derrochador en un sentido y temerario en el otro.
- Di la consecuencia de negocio en voz alta. No "deberíamos refactorizar la capa de sync" sino "si no lo hacemos, cada cliente nuevo tarda tres semanas en onboarding en lugar de un día." Los ejecutivos no están ignorando deuda técnica — se la están contando en un lenguaje que no les permite priorizarla.
- Protege la decisión, no el código. Código hermoso implementando la decisión equivocada es lo más caro que un equipo de ingeniería puede producir, y lo produce gente buena todos los días.
Por qué todo esto importa
Si eres fundador sin background técnico, la persona que más necesitas no es el mejor ingeniero que puedas pagar. Es alguien que te diga que lo que pediste no vale la pena construir — y que tenga suficiente cicatriz como para tener razón.
Si eres CTO y tu CEO parece irrazonable, usualmente está optimizando una variable que no ves, en un reloj que no te muestran. Eso es un problema de traducción, no de competencia.
He sido el fundador que construyó lo equivocado cuidadosamente, y el ingeniero que tenía razón sobre el código pero se equivocaba en lo que importaba. Estar equivocado desde ambas sillas es, que yo sepa, la única forma de aprender dónde está realmente la brecha.