Los más importante para una startup que todavía no ingresa más de lo que gasta, o incluso que todavía no factura nada, es demostrar que su producto tiene mercado, que hay empresas o personas dispuestas a pagar por él. Lo más importante es facturar antes de quedarse sin gasolina (dinero). Si tienes una startup recién creada, te conviene invertir lo mínimo en desarrollo de software propio, salvo que hablemos de un proyecto que cuenta desde el inicio con varios millones de dólares de inversión privada o que la solución tecnológica sea muy disruptiva. Si la startup gira alrededor de un producto tecnológicamente puntero como un algoritmo revolucionario, tiene sentido que se destine dinero a la construcción del producto. En todos los demás casos, no es buena idea emplear el dinero en hacer software a medida desde el comienzo, porque es demasiado caro. La mayoría de las startups no triunfan por su tecnología, sino por la combinación de buenas decisiones con una excelente ejecución y con determinación, más un excelente marketing y una poderosa red de contactos. Es decisivo estar en el lugar adecuado en el momento adecuado y tener la tenacidad suficiente como para aguantar los baches que vengan hasta ver florecer el negocio.
Si eres bootstrapper y tienes conocimientos de programación, no encargues el desarrollo a otra empresa y no contrates developers; invierte tu tiempo en programar el producto como buenamente puedas y guárdate el dinero que tengas para hacer campañas de marketing y para sobrevivir. Sal a producción lo antes posible, con un producto que te avergüenza, que dista mucho de lo que sueñas, pero que te permitirá validar el concepto en el mercado. Consigue dinero.
En 2005, tuve la suerte de conocer en persona a Jon Green, ambos tuvimos por cliente a la misma empresa durante unos meses en Tenerife. Por aquel entonces, yo trabajaba en mi primera empresa, que había montado con tres amigos. La historia de Jon es impresionante. No era developer, pero era muy curioso y visionario. Un par de años antes, había aprendido por su cuenta algo de programación web con PHP, mirando en libros y revistas (no existia StackOverflow entonces, ni muchísimo menos). Jon veía mucho potencial en las webs dinámicas con bases de datos (algo relativamente novedoso en la época), así que aprendió lo justo para poner en marcha la web TenerCoche.com, un sitio de compra-venta de vehículos usados. En cuestión de un par de años, aquella web era de las más visitadas de todo el país, creo recordar que fue líder durante un tiempo. Jon triunfó a lo grande, pegó un buen pelotazo y lo hizo todo él solito, con sus conocimientos de developer amateur (la web era fea como el demonio). Tuvo la suficiente fe en sí mismo como para aprender y experimentar, así como la tenacidad para volcarse con su proyecto hasta alcanzar el éxito, contra todo pronóstico. La historia de Jon fue para mí super inspiradora, porque me hizo creer que desde un lugar tan lejano de Sillicon Valley, también se podía tener éxito. Además, Jon es muy buena gente, alegre y positivo.
En 2010, lancé mi propia web startup, una plataforma que estuvimos desarrollando durante más de un año sin validar la idea en el mercado. Se llamaba MavenCharts. Cuando salimos a producción, nos quedaba poquito dinero para marketing y fue cuando me dí cuenta de que, sin eso, no llegaríamos muy lejos. Desde luego, era en lo que más perdidos estábamos. No tuve la determinación de seguir buscando financiación y, aunque teníamos usuarios, no éramos capaces de facturar dinero. Así que, unos meses después, decidí abandonar la idea. Me dí cuenta tan tarde de que no hice la inversión en el orden adecuado, que ya no me quedaba combustible para pivotar. La idea era buena, como casi todas las ideas, pero el modelo de monetización no casaba con nuestra capacidad financiera. No conocía Lean Startup en ese entonces y nos la pegamos bien, aunque aprendimos un montón.
El código fuente de MavenCharts tenía una cobertura de test mayor al 90%, habíamos hecho el software con la mejor calidad que sabíamos. Sin embargo, el desperdicio no estuvo en los test, sino en el 90% de las features que habíamos implementado y que jamás se usaron. Diseñamos una mega arquitectura super escalable que nos costó meses y que jamás hizo falta, porque con un solo servidor y una base de datos cualquiera, un monolito, habría resuelto durante años. Además, elegimos una tecnología que estaba en pañales y nos dio muchos quebraderos de cabeza, porque no la entendíamos, no funcionaba como esperábamos, no encontrábamos suficiente documentación ni ayuda en foros y se nos hizo muy cuesta arriba. Nos flipamos con la tecnología, la arquitectura y las funcionalidades, y así malgastamos nuestro escaso dinero. Quisimos que la experiencia de usuario fuera innovadora, extremadamente cómoda y potente, lo cual fue un gran error. Si volviera atrás en el tiempo, o si montase otro producto propio, lo único que repetiría es la cobertura de test del 90%+, porque cuando sabes escribir test con eficacia, la diferencia de tiempo invertido en test no se nota y la cadencia desarrollando se mantiene alta durante todo el ciclo.
La mayoría de startups dicen que no escriben test, porque no tienen tiempo, pero, en realidad, no lo hacen porque no saben. Si no sabes una técnica y te pones a trabajar con ella, lógicamente, la cantidad de tiempo que dedicas es gigante. Si quiero construir una pared con bloques y cemento sin saber, mirando vídeos de Youtube, está claro que voy a tardar mil veces más que un albañil experimentado y que el resultado será de mucha peor calidad. Así que lo que se oye habitualmente es “aquí no hay tiempo para los test porque somos una startup”, cuando en realidad lo que no hay es experiencia ni conocimiento. Si yo invirtiera en una startup y participase en el proceso de selección, me ocuparía de que las personas que entran como desarrolladoras tuvieran soltura escribiendo test. Si no, como mínimo, invertiría unas semanas en una formación potente para el equipo, así como en personal experimentado en buenas prácticas que acompañase durante un tiempo ¿Por qué esta inversión en test? Porque cuando sabes escribirlos, el desarrollo va más rápido, ya que prácticamente no se destina tiempo a depurar bugs. La cadencia de desarrollo es constante y predecible, de manera que los planes de negocio son más factibles en tiempos y en calidad. Una cosa es que el producto de la startup tenga pocas funciones, y otra es que falle más que una escopeta de feria, porque entonces tus pocos usuarios pierden la confianza que tanto te ha costado ganar. Si el cerebro de tus developers es tan brillante que no cometen bugs y que siempre avanzan a buena velocidad, quizá no necesites muchos test, pero conviene ser un poquito humildes y darse cuenta de que, personas con estas cualidades, hay una entre millones. En el “mundo real”, la mayor parte del tiempo se va a esfumar leyendo código escrito con prisas, así como buscando y arreglando bugs.
Una buena estrategia marca la diferencia en el éxito de la startup. Pensar antes de hacer es clave para invertir en aquello que da el mejor retorno de inversión en cada momento. Simplifica todo lo que puedas, elimina todo lo que no sea estrictamente imprescindible par alcanzar la meta más próxima. Lucha por sobrevivir hasta el siguiente hito. Escribe la menor cantidad de código posible, apóyate en soluciones software que ya estén hechas y que puedas comprar o alquilar. Resuelve problemas manualmente hasta que valides cada hipótesis y luego piensa en automatizar. Cuando no te quede más remedio que programar, hazlo con test, porque te salvarán el pellejo más de una vez. Lo barato te puede salir muy caro.
Sobre cómo escribir test y código sostenible, he hablado intensamente en mis dos últimos libros:
En Lean Mind, nos encanta ayudar a empresas tecnológicas a construir su software con calidad, con un buen respaldo de test y con código simple y fácil de mantener. Por favor, no dudes en contar con nosotros para ayudarte a poner en marcha esas buenas prácticas que te permitirán avanzar a la máxima velocidad.
¿Quieres más? te invitamos a suscribirte a nuestro boletín para avisarte cada vez que recopilemos contenido de calidad que compartir.
Si disfrutas leyendo nuestro blog, ¿imaginas lo divertido que sería trabajar con nosotros? ¿te gustaría?
Pero espera 🖐 que tenemos un conflicto interno. A nosotros las newsletter nos parecen 💩👎👹 Por eso hemos creado la LEAN LISTA, la primera lista zen, disfrutona y que suena a rock y reggaeton del sector de la programación. Todos hemos recibido newsletters por encima de nuestras posibilidades 😅 por eso este es el compromiso de la Lean Lista
