Lo primero que os diré es que el dinamismo de una startup no permite estar esperando la solución perfecta. Recuerdo una startup argentina afincada en Madrid con la que estuve colaborando a principios de este año que tenia como lema "Es mejor hecho que perfecto", un lema con el que coincido, al igual que coinciden Elon Musk, Sheryl Sandberg y Mark Zuckemberg entre muchos otros que lo han acuñado en alguna ocasión.
Esta frase va muy alineada con "El que golpea primero golpea dos veces", pero hay que saber dar el golpe, y de esto va este artículo. Hecho sí, perfecto no hace falta, pero ... ¡bien hecho!
Una startup requiere entrega constante de valor, esto implica muchas veces tener que pulir el diamante varias veces después de haberlo vendido. Esto es porque la filosofía del no imponer sino convencer se ha impuesto en el mercado digital donde el usuario es quien dicta las normas y las startups nos movemos al son que ellos marcan, porque nuestro mercado son ellos, los usuarios digitales.
Un MVP bien entendido debería ser lo mismo que pulir varias veces un diamante después de haberlo vendido.
Por lo tanto, la forma de trabajar que el mercado digital impone es crear una maqueta (o MVP), probarla e iterarla hasta que el usuario esté satisfecho. En las empresas digitales reales en algún momento se establece como aceptable una determinada versión y el equipo pasa a otra cosa, este cambio normalmente se hace por un tema de prioridades (es más prioritario desarrollar o mejorar otra funcionalidad que la funcionalidad actual). En empresas referentes en producción digital como Spotify hay equipos especializados en partes de la aplicación que mejoran constantemente las funcionalidades.
Dentro de este mercado que tiene por un lado al inversor pidiendo la entrega de valor constante y al usuario cambiante al que entender y satisfacer en todo momento. Los productos digitales requieren de una gran capacidad de adaptación al usuario a la par que una base estable que permita dicha adaptación. Para ello es imprescindible modularizar la aplicación para poder garantizar su escalabilidad funcional y el crecimiento del producto digital.
Desde hace años la industria digital lleva trabajando en la modularización de las aplicaciones, una tendencia que se ha llevado al extremo en los últimos años con los microservicios y microfrontends. Y es este "modelo de desarrollo" el que funciona para que el MVP sobreviva después de varias iteraciones. Necesitamos construir frontends de forma rápida (y con ciclos de vida más cortos) conectados con backends de larga vida, escalabilidad y estabilidad. Un sistema de este estilo nos permite trabajar el prototipado rápido y funcional, nos permite lanzar al mercado productos 100% funcionales en tiempos récord y sin necesidad de demasiados perfiles fullstack, podemos tener a un equipo de growth trabajando desde el diseño, maquetación y frontend conectando con garantías las maquetas al back, muy bien, pero antes de tener esto ¿qué necesito?
Muy simple, antes de esto necesitas tener definida tu arquitectura de desarrollo, aunque no toda. Atento porque aquí está la clave … necesitas tener claro dónde quieres llegar e ir aprovechando el desarrollo del MVP para desarrollar solo aquellos módulos de la arquitectura que necesites, los que no, deberás harcodearlos, y es que la clave, cómo siempre, está en el equilibrio, en saber balancear lo perfecto con la entrega a tiempo.
Código de arquitectura harcodeado = Deuda técnica
Ahora, alguno me dirá, si harcodeas, después tendrás que retrabajar, por lo tanto lo que anunciabas al inicio del post ya no se cumple… y en parte es cierto, pero os diré que tanto en mi etapa de consultor como en mi etapa de CTO me ha tocado descartar software carísimo porque era software diseñado para ser un MVP, software lleno de parches para intentar alargar su vida adaptándolo a las pivotaciones del negocio hasta que todo colapsa y ya no tiene sentido seguir adelante con ese software.
Sin embargo, si somos capaces de tener un modelo objetivo de la arquitectura desde el principio, tener un software que estructura el backend, el frontend y las apis por dominios no tiene porqué ser más caro (si somos capaces de balancear lo necesario de lo deseable en nuestra arquitectura) y nos permite ir puliendo el diamante después de haberlo vendido.