Hay una pregunta que nos hacen a menudo cuando explicamos que además de trabajar con clientes, desarrollamos nuestros propios productos: ¿No os distrae? ¿No es mejor enfocarse?
La respuesta corta es no. La respuesta larga es este artículo.
El problema con construir solo para otros
Trabajar como consultor técnico tiene una trampa sutil: puedes ser muy bueno tomando decisiones que parecen correctas pero que nunca experimentas en sus consecuencias.
Diseñas una arquitectura de microservicios. El cliente la implementa. Seis meses después, cuando el equipo de tres personas lleva tres horas depurando un problema de consistencia eventual que se manifiesta solo en producción, tú ya no estás. Has cobrado, el trabajo estaba técnicamente bien hecho, y nunca sabrás qué fue vivir con esa decisión.
Eso crea lo que llamamos internamente el problema del consejero sin skin in the game: das buenos consejos en abstracto porque nadie mide si esos consejos envejecen bien.
Lo que cambia cuando eres el cliente
Cuando construyes NimblyMath o MathBattle, algo cambia fundamentalmente: tú eres quien va a vivir con cada decisión de arquitectura. Tú eres quien va a depurar el bug de producción a las 2 de la mañana cuando los usuarios están activos. Tú eres quien va a pagar la factura de AWS cuando esa decisión de escalado que parecía elegante resulta ser cara.
Eso te hace pagar un precio de admisión muy real a cada decisión técnica.
Tres lecciones concretas que hemos llevado a proyectos de clientes
1. La deuda técnica tiene un coste emocional, no solo técnico
Cuando tienes deuda técnica en tu propio producto, la sientes diferente. No es un trabajo pendiente en el backlog de otra empresa. Es algo que te frena cada vez que quieres mover rápido. Esa fricción acumulada es un coste real que afecta a la velocidad del equipo, al ánimo y a las decisiones de priorización.
Ahora, cuando evaluamos la deuda técnica de un cliente, somos mucho más específicos sobre cuándo hay que pagarla y cuándo no. Hemos aprendido que no toda deuda es igual: hay deuda que paraliza y deuda que simplemente existe. La diferencia importa más que la cantidad total.
2. La escalabilidad prematura es el error que más hemos cometido
En MathBattle, diseñamos el primer sistema de matchmaking para soportar 10.000 usuarios concurrentes. Pasamos tres semanas en esa infraestructura. En el mes de lanzamiento, el pico fue de 140 usuarios.
Ese tiempo — tres semanas de ingeniería de un equipo pequeño — es un coste de oportunidad enorme. Con esas tres semanas podríamos haber iterado tres veces sobre la experiencia de usuario, que era lo que realmente movía la retención.
Desde entonces, cuando trabajamos con startups o productos en fases tempranas, somos mucho más directos sobre qué arquitectura corresponds a qué momento del producto. El sistema perfecto para escalar a un millón de usuarios es el sistema equivocado si tienes 500.
3. Las decisiones de tecnología tienen consecuencias de equipo
Cuando elegimos el stack de NimblyMath, tomamos algunas decisiones de tecnología que en el momento parecían menores. Meses después, esas decisiones determinaban qué perfiles podíamos contratar, qué herramientas podíamos usar y qué tan fácil era hacer onboarding de nuevas personas.
Eso no lo verás en ninguna comparativa técnica de tecnologías. Solo lo aprendes cuando tienes que convivir con la decisión en un equipo real, con personas reales, durante tiempo real.
La paradoja del constructor
Hay algo que nos resulta fascinante de este modelo: construir producto propio nos hace más conservadores, no más arriesgados.
Cuando tienes que ser tú quien soporte las consecuencias, desarrollas un instinto muy afinado para distinguir complejidad esencial de complejidad accidental. Para saber cuándo una solución elegante es también una solución correcta, y cuándo es solo elegante.
Esa diferencia — entre lo que parece bien ingenierizado y lo que funciona bien en producción durante años — es exactamente el criterio que intentamos aportar cuando trabajamos con los productos de nuestros clientes.
No lo teorizamos. Lo vivimos primero.