¿Cuánto tiempo necesitas para lanzar tu MVP?

Mucho menos de lo que piensas

La semana pasada hablamos sobre cómo utilizar un MVP para validar algo antes de invertir demasiado tiempo. A raíz de ese artículo, me surgió una duda: ¿qué tan rápido puedes crear algo verdaderamente mínimo, pero que sea viable para validar?

Siempre oímos historias de funcionalidades que se validan con un mockup o cómo puedes utilizar una landing page con un correo para medir interés. El problema de estos experimentos es que siempre se quedan a un paso crucial de la verdad que determinará el éxito o el fracaso de tu producto.

¿Hay alguien en este planeta que realmente NECESITE lo que quiero construir?

Ojo, que lo necesite. Seguro que hay mucha gente encantada de probar el freemium y no volver nunca más. Pero, ¿alguien lo necesita?

Así que me propuse validar la parte que muchas veces queda como incógnita:

¿Cuánto tiempo tardo en montar algo que se parezca al producto final?

Como esta pregunta siempre requiere un "depende" para ser contestada, voy a definir un poco más lo que quería validar.

Cuánto tardo en montar un producto que:

• Tenga un sistema de registro para personalizar las interacciones con el usuario final

• Guarde los datos en algún sitio, para que el usuario pueda tener continuidad dentro del producto

• Contenga lógica de negocio (que la funcionalidad en sí misma no sea únicamente guardar datos)

• Esté disponible para todo el mundo (desplegado en producción)

Como no, para que este MVP tenga algo de magia, he desarrollado toda la aplicación usando herramientas de IA (ChatGPT y Cursor) para acelerar más el desarrollo.

Sé lo que estáis pensando: te has puesto a montar un producto antes de validar la idea. ¿No es eso lo contrario a lo que cuentas en el blog sobre validar antes de desarrollar, hablar con el usuario y todas esas cosas?

La realidad es que no. Venimos de unos años enfocándonos tanto en la idea de que hay que validar el problema, el mercado y el diseño, que se nos ha olvidado que también hay que validar la tecnología. Todos los avances de los últimos años en desarrollo de software, algoritmia, IA, etc., han reducido la incertidumbre tecnológica, pero sigue habiendo un componente de incertidumbre que hay que validar. En este caso, la pregunta es: ¿cuánto tiempo necesito para sacar algo al mercado y poder empezar a validar con usuarios reales? ¿Un año? ¿Un trimestre? ¿Un mes? ¿Una semana? ¿Un día? ...

Por ello, me he tomado ciertas libertades para sacar un MVP lo más rápido posible.

Todo vale

Gracias a ChatGPT y Cursor, ha sido como hacer un curso rápido de React: lo justo para que funcione y para entender un poco cómo opera el framework.

No creo que todo el código sea súper limpio, pero sí he utilizado una estructura de aplicación estándar, haciendo uso de componentes y contextos, para que el código no fuese muy terrible.

Para gestionar a los usuarios y el almacenamiento, he utilizado Firebase Authentication y Firestore Database. Básicamente, pude tener un login con Google y una base de datos no estructurada sin tener que gastar mucho tiempo en configuración. Seguro que quien venga detrás a migrar el proyecto se llevará las manos a la cabeza, pero a mí me ha servido.

Por último, para publicar el proyecto he utilizado Netlify vinculado con GitHub para desplegar el proyecto cada vez que hacía un commit. Al principio intenté hacerlo con el hosting de Firebase, pero me pedían subir de plan y no quería pasar la mitad del tiempo revisando cuánto me iban a cobrar por esto. Con Netlify tienes un pipeline de CI/CD (el mío sin tests por supuesto) listo desde el primer momento sin tener que preocuparte por nada.

Funcionalidad clara pero sencilla

Una de las razones que me permitió hacer el proyecto tan rápido fue tener un alcance acotado. El objetivo del proyecto era crear una calculadora para estimar el número de años que me faltan para alcanzar la independencia financiera (FIRE). El principal motivo para centrar el proyecto en este tema es que hay mucha documentación disponible y te permite hacer cálculos sencillos con euros, como sumar conceptos, agruparlos y aplicar porcentajes. Además, es un tema suficientemente genérico como para que pueda interesar a cualquiera, por lo que he conseguido suficientes beta testers para las primeras pruebas.

Lo que más me impresionó fue el PDR que hizo ChatGPT con un prompt muy corto que me sirvió para crear una calculadora entera que funcionó a la primera.

Fuera de la universidad, no se considera copiar

Si esto hubiera sido un examen de React en la universidad, me habrían suspendido por copiar. Como ya no estamos en la universidad, he hecho todo lo posible por evitar consultas a Google gracias a estas herramientas.

Uno de mis objetivos con este proyecto era probar ChatGPT o1. Para quien no lo haya probado, solo puedo decir una cosa: hay que probarlo. Hay que abrir dos ventanas, una con GPT-4 y otra con el o1, y probar el mismo prompt. No probéis el de contar cuántas erres hay en strawberry, eso ya lo ha probado mucha gente. Probadlo para resolver un problema. Es increíble cómo ha cambiado la forma de obtener contexto del GPT-4 al último modelo.

ChatGPT fue quien me guió en toda la configuración inicial del proyecto:

• Cómo instalar npm y React

• Cómo crear un proyecto

• Cómo configurar el proyecto en Firebase

• El código de las primeras páginas

• ...

Una vez que tenía el primer helloWorld con una pantalla de login y un dashboard estático, salté a Cursor. A ChatGPT se le estaba empezando a hacer bola todos los cambios que estaba haciendo en el proyecto para corregir cosas y de los que él no era consciente.

Cursor tiene dos ventajas principales:

• Tiene varios modelos disponibles y los utiliza automáticamente según lo que necesitas

• Tiene en todo momento todo tu código disponible para usarlo como contexto en tu prompt

Tener todo el código disponible para las consultas hace que la herramienta dé un salto de calidad sustancial, sobre todo a la hora de corregir errores. Una variable que has declarado en un sitio pero no estás importando correctamente en el fichero actual, una estructura de datos que no encaja con la función que estás usando, ...

Aun así, tiene sus limitaciones. Me ha reescrito algunas partes del código con otro formato, lo que ha generado errores que he tenido que corregir a mano. También hay momentos en que, si no has seleccionado bien los archivos sobre los que haces la consulta, puede que te inserte una petición a una URL inventada. Además, como gran parte del código no lo has escrito tú, a veces encontrar la línea donde está el error se vuelve una caza de brujas. Al fin y al cabo, que compile no quiere decir que haga lo que tiene que hacer perfectamente.

---

Para mí, la conclusión es clara. Si no sabes programar en React (pero algo sabes), tienes una idea clara y no tienes ninguna restricción técnica que te obligue a hacer las cosas de forma distinta a lo que te indican estas herramientas, probablemente en un día de trabajo seas capaz de sacar algo para validar tu idea con usuarios reales. El tiempo entre el primer commit y el último han sido 5 horas (quitando que lo he hecho durante la semana en tres días). Es verdad que esto es un producto frágil, que en cualquier momento puedes encontrarte con que la arquitectura que has decidido montar no escale y te obligue a rehacer partes de la aplicación, o incluso que cuando entre alguien que sepa, le toque reescribir todo para abordar los siguientes retos. No importa. Lo importante es que ya no hay excusa para no lanzar tu producto y ver si tus usuarios lo usan y vuelven. Ya no puedes decir que lo único que enseñas es un Figma porque no sabes programar.

El mundo avanza muy deprisa; si no aprendemos con él, un día seremos nosotros los que nos quedemos atrás mientras otros siguen evolucionando.

Si después de esto tenéis interés en probar mi MVP, podéis registraros aquí. Hay alguna que otra cosa que me pone de los nervios. Si la encontráis y me lo decís, me pondré a corregirla 🙂