- Un proyecto paralelo iniciado en 2018 tuvo un MVP listo en pocos días, pero al seguir posponiendo la fecha de lanzamiento terminó convirtiéndose en un proyecto de 2 años que nunca salió
- En el centro de la demora estuvo la decisión repetida de “solo una cosa más”, y el alcance del producto creció hasta aprender React Native y Expo
- Una app competidora que resolvía el mismo problema era lenta y tenía bugs, pero ya estaba lanzada, tenía usuarios y comunidad, y mejoraba cada semana
- Después del período de prueba de 30 días, al pagar por la app competidora, su propia app —que solo existía en el disco duro— se convirtió en un producto prácticamente muerto
- En una actualización de 2024, cuenta que finalmente lanzó la app de productividad Benji en 2022, y que aunque la conclusión suene trillada, se inclina por lanzarlo primero
Por qué no pudo lanzar en 2 años un MVP hecho en pocos días
- Empezó a desarrollar la app el 1 de enero de 2018, y el MVP estuvo listo en pocos días
- Incluso la versión alfa 0.0.1 estaba en condiciones de publicarse, pero fue posponiendo el lanzamiento cada vez con la excusa de “una función más”, “una pantalla más”
- Al pensar que “si no hay una app móvil nativa de verdad, la gente no la va a usar”, aprendió React Native y decidió dedicarle algunos meses más
- Después, durante 2 años, se repitieron cambios entre la plataforma web, React Native, Expo, GraphQL, dudas sobre el stack tecnológico, el paso a otros proyectos, el lanzamiento de otras apps como Sizzy, la pérdida de motivación y su recuperación
- Al final dejó de desarrollar y también abandonó la idea de lanzar esa app
El momento en que encontró una app que resolvía el mismo problema
- Con el paso del tiempo, al seguir usando su propia app, sintió que necesitaba muchas funciones más, así que tuvo que decidir entre volver a desarrollarla o buscar una alternativa
- Al ver la landing page de una app alternativa, le golpeó con fuerza la sensación de que alguien ya había resuelto el problema que él quería resolver
- Antes había enviado un video de su app a unas pocas personas, así que sintió que las funciones y la visión del problema eran tan parecidas que hasta sospechó si ese video se habría compartido
- Pero aceptó que la existencia de la app competidora no era culpa de ellos, sino de que él fue demasiado lento y no lanzó a tiempo
La app competidora había priorizado lanzar antes que la perfección
- Mientras creaba una cuenta y veía los videos del centro de ayuda, cada vez que pensaba que la implementación era ingeniosa también era consciente de que se trataba de su competidor
- Durante 2 años había pensado que su propia app era torpe, tenía bugs y le faltaban funciones, así que nadie la usaría, pero al probar la app competidora vio que ese juicio estaba equivocado
- La app competidora también llevaba años en desarrollo, pero seguía siendo lenta, tenía bugs y todavía no estaba muy pulida
- La app móvil era tan mala que la sincronización tardaba 10 segundos, pero ya era un producto lanzado, y los usuarios podían esperar la siguiente actualización
- Aunque la lista de tareas fuera grande, seguían lanzando cada semana y la app y la comunidad crecían juntas
La lección que quedó después de pagar
- Cuando terminó la prueba de 30 días, ingresó los datos de su tarjeta de crédito y dejó de ser un simple suscriptor para volverse fan
- La notificación del pago quedó como una experiencia que le recordaba una y otra vez que él no había logrado lanzar su producto
- En ese momento aceptó que su app estaba oficialmente muerta
- La mayoría de las personas que están en una situación parecida quizá apenas llevan unas semanas con su proyecto, así que deberían evitar cometer el mismo error
- Si “solo una cosa más” significa volver a construir autenticación, pagos y boilerplate, eso es una trampa; después creó Zero To Shipped para reducir esa trampa
Actualización de 2024: finalmente lanzó Benji
- Según una actualización de 2024, finalmente lanzó Benji en 2022
- La razón para lanzarla fue que ninguna app competidora se acercaba lo suficiente a su visión
- La app que quería era una combinación de Todos, Habits, Planner, Goals, Pomodoros, Meal tracking, Fasting, Hydration, Packing y Trips
- Benji también tiene una línea de tiempo pública donde la gente mejora su vida y comparte su éxito y sus logros
- Aunque suene trillado, hay que respirar hondo y aun así Just Ship It
1 comentarios
Opiniones de Hacker News
En estas historias de “todo terminó porque no lo lanzaron en ese momento” hay una gran pista: a veces el valor de la app que estaban construyendo está en detalles técnicos que no se pueden apurar, y en esos casos “simplemente lánzalo” no es la respuesta.
El trabajo de un ingeniero/arquitecto de software también consiste en resistir, en la medida de lo posible, la presión de la gerencia de “sáquenlo ya”. Si es un producto propio y el lanzamiento te beneficia personalmente, es otra situación; si no, y dedicar más tiempo produce un resultado más profesional, entonces hay que tomarse ese tiempo. No somos máquinas automáticas que reciben tickets de JIRA y escupen código descuidado lo más rápido posible; si trabajas así de forma continua, te desgastas mentalmente y al final llega el burnout.
Si no tienes participación accionaria en la empresa, tu trabajo no es maximizar las ganancias de la compañía, sino crear buen software que no te dé vergüenza poner en tu currículum. El alivio de cumplir otra fecha límite arbitraria es solo una motivación negativa de corto plazo y no dura; hay que resistir la presión que viene de arriba y hacerlo bien. Incluso si te despiden, hoy en día cambiar de empleo de todos modos suele ser la forma de avanzar.
Dicho eso, rentabilidad no significa lo mismo que “simplemente lánzalo”. Si una empresa confunde ambas cosas con frecuencia, es señal de falta de seniority del lado de la gerencia.
El trabajo de un desarrollador se parece más a construir un buen producto que a construir “buen software”. Un buen producto por lo general necesita buen software, pero no siempre; también hay muchos casos de productos excelentes con software pésimo detrás. La tensión entre producto, ventas y desarrollo debería llevar a compromisos que maximicen el valor a corto, mediano y largo plazo, y el desarrollador debe entender qué se puede resolver de forma aproximada, qué prioridades tiene la empresa y cuándo no hay que ceder y sí construir buen software.
Un desarrollador que nunca puede ceder en calidad de software pierde fuerza incluso en los momentos en que realmente no se debe ceder.
Por eso la prioridad número uno es crear valor para los usuarios y desarrollarlo de la forma más eficiente posible. ¿Qué sentido tiene un software que nadie usa?
El trabajo de un desarrollador no es crear buen software, sino entregar valor al usuario. En mi carrera, de hecho he visto más bien lo contrario: desarrolladores embriagados por el sobrediseño, inflando el código con funciones que nadie necesita y agregando código para prepararse para desarrollos futuros que quizá nunca lleguen. Por eso el desafío difícil es mantenerse minimalista, y el texto original parece ir por ahí.
En empresas pequeñas y medianas definitivamente hay que hacer concesiones, y tomar decisiones que lleven al mejor resultado de negocio también forma parte del trabajo profesional.
Muchos desarrolladores están “protegidos” por varias capas de gerentes, PM y diseñadores, así que tienen poca conexión con el lado del negocio. Si sacas el producto rápido, también recibes feedback rápido y tienes la oportunidad de evaluar si la implementación coincide con tus supuestos. Me resultó menos estresante que desplegar una solución “perfecta” bajo presión y luego tener que reescribirla.
En mi trabajo actual como desarrollador, lo que hago es reducir la complejidad y lograr que PM y diseñadores recorten el plan inicial al mínimo. Así las fechas límite arbitrarias también se vuelven menos estresantes y el impacto de los retrasos es menor.
La parte valiosa sería, como mucho, no obsesionarse demasiado con un empleo específico ni preocuparse de más por un despido, pero creo que la explicación de por qué también está equivocada. Me sorprende que de verdad pueda estar trabajando con personas que tienen una actitud tan adversarial.
Parece que a algunas personas les gusta vivir en el cuadrante equivocado de la teoría de juegos.
Al leer la parte de “sospeché quién les había compartido el video de mi app a estas personas, porque estaban resolviendo literalmente el mismo problema”, recordé una vez que conocí a alguien con una idea de app bastante buena.
Me pidió que le programara la app gratis y que repartiéramos las ganancias. Cuando le pregunté qué aportaría él, respondió que “operaría” la empresa, y que su 50% era “porque se le había ocurrido la idea”. Así que le dije que le daría seis meses de ventaja, y que si para entonces no la llevaba al mercado, la construiría yo mismo.
Dos de los tres simplemente se sentaron y empezaron a darle forma, pero el tercero subió código roto a SVN, hizo un documento de diseño atribuyéndose toda la idea, convocó una reunión y dijo que él era el diseñador del juego y que nos demandaría si hacíamos un juego en otro lugar. Los dos que sí estábamos contribuyendo nos miramos y dimos por terminado el proyecto. Él había mostrado todas sus cartas y quedó claro que no era gran cosa.
Más tarde vi en Steam un juego con una idea parecida. Si se les ocurrió de forma independiente, bien; si se la robaron a ese tipo, también bien; y si aguantaron trabajando con él hasta el final, se merecen el dinero.
Si la idea realmente era buena y creíble, sinceramente quizá habría sido una propuesta bastante decente.
Si crees que está bien decirle a alguien “dentro de seis meses voy a robar tu gran idea”, más vale esperar que esa persona no sea del tipo que puede causar problemas o, en el extremo, hacer daño.
Ojalá alguien resolviera mi problema por mí. La razón por la que ahora sigo aferrado a ese problema es simplemente que no existe una solución que pueda comprar y usar
Si alguien sudara sangre para resolver mi problema y además se hiciera cargo del on-call y el mantenimiento, sería algo feliz
¿Por qué tienes que resolver este problema necesariamente tú? ¿Por qué tu solución tiene que ser necesariamente un negocio? Un negocio consiste en crear valor para uno mismo y para los clientes. Si te obsesiona el problema en sí, basta con agradecer que otra persona invierta mucho esfuerzo en resolverlo; si te obsesionaban los clientes, hace mucho tiempo deberías haberles entregado algo para obtener feedback
No creo que haya mucha gente que quiera operar una empresa a largo plazo, pero a la mayoría no le disgustaría recibir de pronto una gran suma de dinero por haber resuelto o abordado un problema interesante
Se me seguían ocurriendo ideas para poner en mi app, pero a otros desarrolladores probablemente no les habría interesado implementarlas. Quería control, y por eso finalmente lancé Benji: https://benji.so
Soy el autor original. Tengo que actualizar este artículo. Años después, los comentarios de HN que aparecían cada vez que se publicaba este texto realmente me motivaron
La gente siempre decía “¿por qué no simplemente lanzas la app?”, así que al final la lancé
Me alegra haber llegado hasta el final, y creo que es mucho mejor que cualquier producto competidor de esta categoría
Se puede ver en https://benji.so. La landing page todavía está en proceso
Mi app tenía un objetivo similar: conectar la motivación de hábitos, la medición del cumplimiento de objetivos y la programación y reprogramación de tareas. Trabajé en ella durante años, y la idea de convertirla algún día en una empresa bootstrap estaba muy ligada a mi identidad
La decisión de dejar el proyecto llegó en varias etapas, pero uno de los grandes cierres fue darme cuenta de que, a largo plazo, no quería vivir como desarrollador de apps. Fue difícil soltarlo, pero ahora estoy conforme con esa decisión. Como en el texto original, podría revivir más adelante, así que también se puede decir que “nada desaparece por completo”, pero no creo que vuelva a este proyecto en particular
Una de las ideas clave para superar la “alta carga cognitiva” que tienen la mayoría de las apps de productividad era un marketplace de módulos de vida. Por ejemplo, un influencer de fitness vendería un paquete con rutinas de ejercicio, dieta y plantillas de diario, y el usuario lo “instalaría” en su propia vida
Los modelos de lenguaje grandes harán mucho más viable detectar el abandono y estimar sus causas, o responder a “acciones no realizadas”. Creo que es importante para las personas que no tienen una personalidad tipo A y no usan apps de productividad de forma constante todos los días
La diferencia con GMT es correcta, pero Brussels, Copenhagen, Madrid, Paris no están en África, así que resulta muy confuso. Sería bueno revisar la información de zona horaria que se está usando
Viendo el comentario de abajo, esto no era un problema
Y perdón por haber expresado frustración y sospecha porque no dijiste el nombre del “competidor”. Ahora que lanzaste tu app, supongo que es incluso menos probable que digas su nombre, aunque ese producto competidor todavía exista
Cuando te conviertes en usuario real de tu propio sistema, la perspectiva cambia por completo. Yo también tenía algo que estaba construyendo para mí, y pensaba que no estaba listo y que era totalmente inutilizable
Después de abandonar el proyecto decidí usarlo como si fuera un usuario real, y me di cuenta de que los usuarios están acostumbrados a montones de problemas pequeños y encuentran automáticamente formas de rodearlos. Quien crea algo suele olvidar que muchas imperfecciones no son motivo de descarte, y que los usuarios esquivan varias carencias sin gran esfuerzo. En ese punto, la búsqueda de la perfección se parece más al orgullo
Ignorar por un tiempo el hecho de que uno lo creó, prohibirse hacer correcciones durante un rato y usarlo de verdad puede cambiarlo todo
En la práctica, hasta que lo expones a usuarios reales no encuentras la mayoría de los “bugs” que ellos van a enfrentar. Si no lanzas, tampoco tienes oportunidad de corregir los bugs que realmente afectan a los usuarios
Simplemente abrí la página web directamente y la usé, y por supuesto el nombre de usuario y la contraseña estaban sincronizados con iCloud. Retomar el flujo de usuario en Safari tomó 5 segundos, y terminarlo solo 30 segundos
No es el mejor ejemplo de “simplemente lánzalo”. Categorías como apps de productividad, tareas pendientes, seguimiento de hábitos, seguimiento de gastos, journaling y planes de ejercicio son ideas que mucha gente se plantea de forma independiente.
No saben lo inteligente que me sentí cuando se me ocurrió la idea de una app para registrar gastos. Y luego revisé la Play Store. KRAZAM también se burló de esto hace 5 años en el video “The Hustle”.
Eso no significa que una nueva variante no pueda tener éxito. La mayoría de las cosas exitosas no son completamente originales. Pero si te preocupa que alguien lance primero su propia versión y te gane, basta con mirar un poco alrededor.
En lo personal, no soporto el estilo de escritura de “esforzarse demasiado por ser gracioso”.
Dejé de leer. Demasiado infantil y da pena ajena.
Al final solo hicieron una prueba de concepto y se conformaron con eso. Es una lástima, pero así es la vida. Hicieron el trabajo y obtuvieron una recompensa.
La lección es que las ideas no se pueden poseer.
Estoy totalmente de acuerdo con esto. Cuando empezamos Kviklet éramos 3, y uno de nosotros era mucho más perfeccionista que los otros dos. Sinceramente, hasta subir la primera versión del sitio web, que era bastante mala, requirió mucha persuasión, y hacer público el repositorio fue todavía más difícil.
Ese “cofundador” se fue al principio, pero me alegra mucho que hayamos intentado lanzar temprano y venderlo.
No salió bien y no encontramos compradores, pero me aterra imaginar que todavía estaríamos construyendo el producto a ciegas, aferrados solo a la esperanza y sin saber en absoluto si alguien pagaría por él.
Ahora lo convertimos en open source como plan B y ya tenemos algunos usuarios bastante geniales. Creo que hasta podríamos llamarlo una pequeña comunidad: https://github.com/kviklet/kviklet
No es la historia de éxito de startup que esperaba hace un año, pero es mucho mejor que seguir viviendo de expectativas sin sentido de realidad. Y que sea open source tampoco significa que no podamos ganar algo de dinero vendiendo soporte o una versión premium, ¿no? Por ahora es simplemente un side project divertido.
Habría que usar palabras como mutation, edit, update o modification. Aunque query sea técnicamente correcto, por connotación suena incorrecto y confuso.
Si estoy creando algo para mí, no me pondría triste porque alguien lo haya hecho primero. Eso solo demuestra que la idea era buena.
Claro que muchos proyectos personales que tengo en la cabeza y en papel, incluso algunos que ya empecé un poco, no están pensados para lanzarse a la venta. Son cosas que yo quiero o que podrían resultar útiles para amigos, familia u otras personas.
Si llegaran aunque sea a una calidad alfa, quizá los publicaría con la esperanza de que alguien piense: “la idea es útil, pero la implementación no es muy buena; debería hacerla mejor yo”.
Además, aunque seas el primero en entrar, pronto aparecerán competidores que erosionarán tu ventaja, y tendrás que esforzarte por mantenerte adelante.
Así que, si de todos modos siempre hay alguien antes y la competencia es segura, ya sea ahora o más tarde, no te preocupes por que se te adelanten y concéntrate en tu ventaja competitiva. Parece que el autor original también terminó llegando a esa conclusión; ojalá le vaya bien.