02 Servicio
De la idea a un producto con usuarios adentro.
Cuando tenés una idea de negocio digital y necesitás saber si funciona antes de gastarte el presupuesto entero en averiguarlo.
Cuándo tiene sentido
Esto no es construir una herramienta para una operación que ya existe. Acá lo que hay que construir es el negocio: todavía no sabés con certeza quién paga, por qué vuelve ni cuánto vale. La pregunta no es "¿cómo lo hacemos?" sino "¿esto le importa a alguien?", y esa pregunta no la contesta una reunión: la contesta gente usando algo.
Suele aplicar cuando pasa alguna de estas cosas:
- Tenés la idea clara y ningún usuario todavía.
- Estás haciendo a mano, con planillas y mensajes, algo que querés convertir en producto para más gente.
- Conseguiste los primeros clientes y el proceso artesanal ya no te da abasto.
- Necesitás algo funcionando para mostrar: a un socio, a un inversor, a un cliente grande que no firma contra una presentación.
Cuándo no nos contrates todavía
Si tu idea se puede probar sin software, probala sin software. Una página que explique la propuesta con un formulario, veinte entrevistas bien hechas o dos semanas resolviendo el problema a mano por WhatsApp te dan la misma respuesta que un desarrollo y cuestan una fracción. Si venís con eso hecho, el MVP arranca sabiendo qué construir y sale más barato.
Y si lo que necesitás es una lista de funciones cerrada porque ya sabés exactamente qué tiene que hacer el sistema, lo tuyo probablemente sea software a medida y no un producto digital. Son trabajos distintos: uno optimiza algo conocido, el otro busca algo que todavía no está.
Cómo trabajamos
1. Recortar antes de escribir código
Una reunión y un documento: quién es el usuario, qué tiene que poder hacer de punta a punta, y la lista de todo lo que queda afuera de la primera versión. Esa segunda lista es siempre más larga que la primera, y es la parte del trabajo que más plata ahorra. Panel de administración, roles múltiples, notificaciones y reportes casi nunca entran en un MVP: se agregan cuando hay usuarios que los pidan.
2. Diseño de producto, no decoración
Primero el recorrido: qué ve alguien que entra por primera vez y cuántos pasos hay entre eso y el momento en que el producto le sirvió para algo. Si ese camino tiene seis pantallas, el problema no se arregla con colores. La interfaz se trabaja después, sobre un recorrido que ya cierra.
3. Salir, medir, cambiar
El MVP sale a producción con medición adentro desde el día uno: cuántos entran, cuántos completan el recorrido, cuántos vuelven a la semana. Sin eso, después de dos meses vas a tener opiniones en vez de datos, y las opiniones siempre le dan la razón a quien tuvo la idea. Cada ciclo siguiente se decide con esos números sobre la mesa.
De la idea al MVP en producción: ocho a catorce semanas. El presupuesto se cierra después del documento de alcance. Si durante el camino querés sumar una función, te decimos cuánto corre la fecha antes de empezarla, no después.
Qué te queda
Un producto en línea con usuarios reales, el código en tu repositorio con las credenciales a tu nombre, y los datos de uso de los primeros meses. Si la idea camina, tenés sobre qué seguir construyendo. Si no camina, tenés la respuesta antes de haberte gastado el presupuesto entero en conseguirla — que es exactamente para lo que sirve hacerlo chico.
Preguntas frecuentes
¿Qué es un MVP y en qué se diferencia de una primera versión?
Un MVP (producto mínimo viable) es la versión más chica del producto que igual le resuelve el problema completo a una persona real y la deja usarlo de punta a punta. No es una versión a medio hacer ni una maqueta clickeable: es menos funciones, pero las que están funcionan de verdad y tienen usuarios adentro. La diferencia con "una primera versión" es la intención: la primera versión busca mostrar el producto; el MVP busca aprender si alguien lo quiere. Por eso un MVP se juzga por lo que te enseñó, no por lo que incluye.
¿Cuánto cuesta desarrollar un MVP en Argentina?
Depende de cuántas funciones entren, y la variable que más mueve el precio no es la tecnología sino el recorte del alcance. Un MVP con registro de usuarios, una pantalla de trabajo y un cobro es un proyecto; el mismo MVP con panel de administración, notificaciones, reportes y tres roles distintos es otro proyecto y puede costar el triple. Nosotros arrancamos con una reunión de una hora y un documento donde se define qué entra, qué queda para después y qué conviene no construir nunca. Recién con ese alcance escrito hay un presupuesto cerrado, y se respeta salvo que cambie el alcance por escrito.
¿Cuánto tarda en salir a producción un MVP?
Entre ocho y catorce semanas desde el documento de alcance hasta tener el producto en línea y con usuarios reales adentro. Ese plazo supone un alcance chico y decisiones rápidas de tu lado: la demora más común en un MVP no es técnica, es que nadie decide qué se saca. Cada función que se suma durante el camino corre la fecha, y lo decimos antes de sumarla, no después.
¿Conviene validar la idea antes de construir el producto?
Casi siempre sí, y a veces la validación no necesita código. Si tu idea se puede probar con una página que explique la propuesta y un formulario, con veinte entrevistas o con un proceso hecho a mano por vos durante dos semanas, hacé eso primero: cuesta una fracción y te da la misma respuesta. Construir tiene sentido cuando la única forma de saber si funciona es que la gente lo use. Si te decimos que todavía no hace falta que contrates desarrollo, es porque nos conviene que el proyecto empiece cuando tiene chance de llegar a algún lado.
¿Qué pasa si el MVP sale y la idea no funciona?
Es un resultado posible y hay que planificarlo desde el principio: por eso el MVP se hace chico. Si a los dos meses los números dicen que nadie vuelve, tenés dos salidas honestas: cambiar el producto apoyándote en lo que ya está construido, o parar. En los dos casos te quedás con el código en tu repositorio, con los datos de uso y con una respuesta que antes no tenías, por una fracción de lo que hubiera costado enterarte después de un año de desarrollo. Lo caro no es que una idea falle; lo caro es descubrirlo tarde.
¿Esto es lo que necesitás?
El primer paso es una reunión de una hora y un documento: qué duele, qué se puede automatizar y qué conviene no construir. Sin costo y sin compromiso.