Alcance mínimo real
Identificamos las dos o tres funcionalidades que prueban o refutan tu hipótesis. El resto espera hasta que el mercado hable, que es cuando el dato vale.
// MVPs PARA STARTUPS
Del concepto al mercado en semanas, no meses.
Construimos el producto mínimo que realmente prueba tu hipótesis de negocio — ni una función más. Con la arquitectura correcta para el día que lleguen los usuarios.
// DEFINICIÓN
¿Qué es un MVP y para qué sirve?
Un MVP (producto mínimo viable) es la versión más chica de un producto que igual permite probar si la hipótesis de negocio se sostiene con usuarios reales. No es una versión incompleta ni una demo: es un producto que funciona en producción, con el alcance recortado a lo que responde la pregunta que importa.
La palabra que más se malinterpreta ahí es «mínimo». No significa hecho a las apuradas ni con la mitad de la calidad: significa que se construye una sola cosa bien, en lugar de diez a medias. Un MVP con un flujo sólido y sin reportes le enseña más al negocio que uno con quince pantallas que nadie termina de usar.
El otro malentendido es tratarlo como algo descartable. El alcance es lo que se acota, no los cimientos. La base de datos, la autenticación y la estructura del código se definen pensando en el producto que viene, porque si la hipótesis se confirma vas a estar creciendo sobre eso, y ese es el mejor problema posible.
// NUESTRO ENFOQUE
MVPs que validan, no que confunden.
Arquitectura que escala
El MVP no es descartable: es el cimiento del producto. Se construye para que crecer sea una buena noticia y no un proyecto de reescritura.
En producción en menos de 8 semanas
Descubrimiento, diseño, desarrollo y lanzamiento con un cronograma cerrado desde el inicio y avance visible en un entorno de preview.
// QUÉ ENTRA Y QUÉ NO
El recorte que hace que un MVP sirva para decidir.
La discusión difícil de un MVP no es técnica, es de alcance. Así solemos dividirlo, y por qué.
| Criterio | Entra en el MVP | Queda para después |
|---|---|---|
| Flujo principal | El recorrido completo que prueba la hipótesis, de punta a punta. | Los caminos alternativos y los casos borde de baja frecuencia. |
| Cuentas y accesos | Registro, login y roles básicos. | SSO, permisos finos por equipo, invitaciones masivas. |
| Cobros | Cobro manual o un checkout simple si el negocio lo exige ya. | Facturación automática, prorrateos, planes y cupones. |
| Administración | Un panel mínimo para operar y desbloquear usuarios a mano. | Backoffice completo, auditoría y reportes configurables. |
| Medición | Analítica de producto sobre los eventos que definen la hipótesis. | Dashboards de negocio, cohortes y atribución. |
| Integraciones | Solo las que el flujo principal no puede evitar. | CRM, facturación, notificaciones y todo lo que se resuelva a mano. |
// DATOS CONCRETOS
Cómo trabajamos, en números.
- Plazo típico
- 6 a 8 semanas Del kickoff a producción con usuarios reales. Lo que más lo estira es sumar funcionalidades en el camino, no la complejidad de lo acordado.
- Etapas
- Descubrimiento, diseño, desarrollo, lanzamiento El descubrimiento y la definición del alcance ocupan las primeras dos semanas: es donde se decide qué no se construye.
- Stack
- React, React Native, Node.js, PostgreSQL Astro para el sitio público cuando el producto necesita uno. La elección se cierra en descubrimiento, no antes.
- Equipo
- Dos referentes fijos por proyecto Diseño de producto y frontend por un lado, backend e infraestructura por el otro. Hablás con quien construye.
- Qué se entrega
- Código, infraestructura y dominios a tu nombre El repositorio queda con acceso completo de tu equipo desde el primer commit. Sin plataformas propias de por medio.
- Después del lanzamiento
- Iteración sobre datos, no sobre opiniones La analítica se instala junto con el producto, para que la primera decisión post-lanzamiento salga de uso real.
//PREGUNTAS FRECUENTES
Lo que nos preguntanantes de empezar.
¿Cuánto tarda desarrollar un MVP?
Entre 6 y 8 semanas desde el kickoff hasta tenerlo en producción con usuarios reales. Ese plazo cubre descubrimiento, definición del alcance mínimo, diseño, desarrollo y lanzamiento. Lo que lo estira casi siempre es sumar funcionalidades durante el camino, no la complejidad técnica de lo que se había acordado.
¿Qué entra en un MVP y qué queda afuera?
Entra el flujo que prueba o refuta tu hipótesis de negocio, normalmente dos o tres funcionalidades, más lo mínimo indispensable para operarlo: cuentas de usuario, un panel de administración y medición. Queda afuera todo lo que se pueda resolver a mano mientras haya pocos usuarios: facturación automática, integraciones secundarias, reportes y personalización.
¿El MVP hay que tirarlo y rehacerlo cuando crece?
No, si se construyó con la arquitectura correcta. Un MVP acota el alcance del producto, no la calidad de sus cimientos: base de datos, autenticación y estructura del código se definen pensando en el producto que viene. Lo que se tira son las funcionalidades que el mercado no validó, y eso es justamente el ahorro.
¿Necesito tener el diseño hecho antes de empezar?
No. El diseño de producto es parte del trabajo: entra en las primeras semanas, junto con la definición del alcance. Si ya tenés identidad de marca o un sistema de diseño, lo tomamos como punto de partida y ahorramos ese tramo. Si no, se construye lo mínimo necesario para que el producto se sostenga visualmente.
¿Conviene hacer el MVP con herramientas no-code?
Para validar demanda antes de escribir código, sí: una landing y un formulario alcanzan. Para un producto con usuarios que vuelven, lógica propia o datos sensibles, el no-code se vuelve el techo del proyecto justo cuando empieza a funcionar. La pregunta útil no es cuál es más rápido, sino qué pasa el día que la hipótesis se confirma.
¿De quién es el código del MVP?
Tuyo, desde el primer commit. El repositorio queda a nombre de tu empresa y con acceso completo de tu equipo, igual que la infraestructura y los dominios. No trabajamos con código cerrado ni con plataformas propias que te aten a seguir contratándonos para poder tocar tu producto.
El mercado tiene las respuestas. Nosotros te ayudamos a hacer las preguntas correctas.
Un MVP mal definido no es barato: es caro. Fallar rápido está bien; fallar por las razones equivocadas, no. Trabajamos para que lo que aprendas del mercado sea accionable el mismo día que lo aprendés.