Escrito por
Nacho Seoane
Publicado el
Compartir
El coste de desarrollar un MVP se calcula sumando definición, diseño, construcción, pruebas y puesta en marcha del recorrido que quieres validar. Para decidir cuánto puedes invertir, añade los gastos de operación y los cambios posteriores. La etiqueta "MVP" por sí sola no determina un precio.
Un presupuesto útil explica qué podrá hacer el usuario, cómo se comprobará la entrega y qué quedará pendiente. Con esa información puedes comparar propuestas y recortar alcance sin descubrir después que falta una parte imprescindible.
TL;DR — Cuánto presupuestar para un MVP
- Define un recorrido antes de pedir precio. Usuarios, reglas, datos e integraciones condicionan el trabajo.
- Separa prototipo y producto utilizable. Probar pantallas y operar con usuarios exigen entregas distintas.
- Compara las mismas partidas. Incluye definición, diseño, desarrollo, pruebas, lanzamiento y continuidad.
- Calcula el primer año completo. Suma construcción, servicios recurrentes, mantenimiento y cambios previstos.
- Pide pruebas de aceptación concretas. El presupuesto debe explicar cómo comprobarás que el recorrido funciona.
- Reserva capacidad para aprender después del lanzamiento. Una primera versión necesita decisiones y ajustes tras su uso.
Cómo calcular el presupuesto del primer año
El presupuesto debe distinguir el coste inicial, los gastos recurrentes y el dinero disponible para nuevas iteraciones. Una fórmula práctica es: construcción y lanzamiento + operación durante el periodo elegido + cambios aprobados.
Ejemplo puramente ilustrativo, sin relación con tarifas de Apogeo ni con una media de mercado: si una propuesta incluyera la primera versión por 9.000 €, infraestructura y mantenimiento por 150 € mensuales, y decidieras reservar 1.200 € para cambios, el presupuesto de 12 meses sería 9.000 + 1.800 + 1.200 = 12.000 €, antes de impuestos.
La reserva no sería un gasto contratado automáticamente. Y esos 150 € solo servirían para comparar si ambos proveedores cubren las mismas tareas, consumos y tiempos de atención. Marketing, captación y operación del negocio requieren su propio presupuesto.
Para estimar tu caso, lleva a la conversación el recorrido principal, quién lo utilizará, los sistemas que debe conectar y el límite de inversión. Pide que se identifiquen los supuestos todavía sin comprobar.
Cuándo pagar un prototipo y cuándo un MVP
Paga un prototipo cuando necesites comprobar comprensión o viabilidad; encarga un MVP cuando necesites observar uso efectivo del servicio. Puedes probar una idea con pantallas y tareas simuladas antes de asumir el coste de cuentas, datos, notificaciones y soporte.
GOV.UK recomienda utilizar la fase alpha para probar las hipótesis más arriesgadas con prototipos que no tienen calidad de producción. Es una referencia de método, no un plazo ni una tarifa para startups. Fuente: How the alpha phase works.
En un MVP pueden quedar tareas manuales: preparar una oferta, revisar una solicitud o ayudar al usuario. Hay que indicar quién las realizará y cuánto esfuerzo requieren. Si tu duda se limita a coordinar entregas y aprobaciones, revisa antes cuándo merece la pena un portal de clientes.
Qué partidas debes comparar entre presupuestos
Compara entregables, exclusiones y criterios de aceptación dentro de cada partida. Un importe menor puede dejar trabajo a tu cargo o aplazarlo a una fase posterior.
| Partida | Qué debería concretar la propuesta | Qué puede aumentar el coste |
|---|---|---|
| Definición | Usuario, recorrido, reglas y límites | Decisiones abiertas o procesos contradictorios |
| Diseño | Pantallas, estados y prueba con usuarios | Más perfiles o recorridos diferentes |
| Desarrollo | Datos, permisos y funciones incluidas | Reglas especiales, aplicaciones nativas o tiempo real |
| Integraciones | Sistemas conectados y acceso disponible | API limitada, datos inconsistentes o sincronización |
| Pruebas y lanzamiento | Casos de aceptación, entorno y entrega | Migraciones, fallos externos o requisitos adicionales |
| Continuidad | Servicios, soporte y cambios cubiertos | Más consumo, horarios de atención o nuevas funciones |
La tabla sirve para igualar el alcance antes de comparar totales; no asigna porcentajes universales. Pide también quién tendrá acceso al repositorio, las cuentas y los datos, y qué documentación se entregará para continuar el trabajo.
Cómo convertir el alcance en una prueba verificable
Describe una tarea que el usuario pueda completar y añade los casos que podrían impedirla. Eso permite valorar el presupuesto con algo más concreto que una lista de pantallas.
Ejemplo hipotético: un servicio permite reservar una sesión formativa. La primera versión podría incluir consultar fechas, elegir una plaza, recibir confirmación y cancelar la reserva. Pagos, bonos y múltiples sedes quedarían fuera si la prueba inicial no los necesita.
Antes de aceptar la entrega, comprobarías que:
- La reserva descuenta una plaza y no permite superar el aforo.
- Un fallo al enviar el correo queda visible para el equipo.
- La cancelación libera la plaza según las reglas acordadas.
- Cada usuario solo consulta o modifica las reservas autorizadas.
Los permisos forman parte de ese trabajo. OWASP recomienda definir accesos, limitar privilegios y probar que las reglas se cumplen. Recortar estas comprobaciones cambia el riesgo de la entrega, aunque la interfaz parezca terminada. Fuente: Authorization Cheat Sheet.
Cuánto cuesta mantener un MVP después de lanzarlo
El mantenimiento se presupuesta por cobertura y necesidades de operación; no hay un porcentaje universal aplicable a cualquier MVP. Separa servicios técnicos, atención de incidencias, actualizaciones y evolución del producto.
Como referencia concreta de una partida, Supabase publica su plan Pro desde 25 USD al mes, con consumos incluidos y cargos adicionales según uso y configuración. Ese importe corresponde a un proveedor de infraestructura, no al mantenimiento completo de una aplicación. Precio consultado el 5 de noviembre de 2026. Fuente: Supabase Pricing.
Pide estimaciones para el uso inicial y para un escenario de crecimiento definido: usuarios, archivos, correos o llamadas a servicios externos. Aclara quién revisa alertas, restaura datos, resuelve incidencias y autoriza gastos. Una cuota mensual sin estas responsabilidades describe poco.
Preguntas frecuentes
Estas decisiones ayudan a ajustar el gasto sin dejar responsabilidades abiertas. Conviene resolverlas antes de aceptar la propuesta.
¿Puedo pedir un precio cerrado para mi MVP?
Sí, para un alcance suficientemente definido y con un procedimiento para los cambios. Pide entregables, exclusiones, dependencias y pruebas de aceptación. Si una integración todavía no se ha podido comprobar, resulta más útil presupuestar primero esa validación que tratar su coste como una certeza.
¿Tengo que decir mi presupuesto al proveedor?
Dar un límite de inversión ayuda a proponer una primera versión que puedas financiar. Explica también qué resultado necesitas validar y qué dinero debes reservar para operar. Solicita alternativas de alcance y sus consecuencias; así podrás evaluar la propuesta por lo que resuelve dentro de ese límite.
¿Un MVP con no-code siempre sale más barato?
Puede reducir trabajo inicial cuando la herramienta cubre el recorrido y sus reglas. Compara también licencias, límites de consumo, integraciones y posibilidades de exportar datos. Si exige muchas adaptaciones o tareas manuales, incluye ese esfuerzo en el cálculo. La tecnología se elige después de comprobar el encaje.
¿La IA reduce el coste de desarrollar un MVP?
Puede ayudar con tareas de implementación, pero el presupuesto debe seguir cubriendo definición, revisión y pruebas. Solicita una entrega verificable con independencia de las herramientas utilizadas. Si el producto incorpora IA para sus usuarios, suma además el consumo del proveedor y las pruebas de sus respuestas.
¿El mantenimiento incluye nuevas funcionalidades?
Solo si la propuesta lo especifica. Distingue corregir un incumplimiento del alcance, mantener el sistema en funcionamiento y añadir una capacidad nueva. Pide ejemplos de cada categoría, el procedimiento para aprobar cambios y qué ocurre al terminar la cobertura. Esto facilita comparar cuotas que parecen similares.
Recomendación final
Pide presupuesto para un recorrido verificable y compara el coste de mantenerlo durante 12 meses. Exige un desglose, pruebas de aceptación y responsabilidades posteriores. Si todavía desconoces si alguien necesita el servicio o si una integración es viable, empieza por una validación acotada antes de encargar la construcción completa.
En resumen
- El precio necesita un alcance. Define usuarios, reglas, datos e integraciones antes de comparar propuestas.
- El prototipo permite probar hipótesis. Su entrega y sus garantías difieren de las de un producto operativo.
- Revisa todas las partidas. Definición, diseño, construcción, pruebas, lanzamiento y continuidad deben quedar claras.
- Compara un periodo común. Un cálculo de 12 meses hace visibles costes posteriores a la entrega.
- Acuerda pruebas concretas. Comprueba el recorrido, sus errores y los permisos de acceso.
- Aclara qué cubre el mantenimiento. Infraestructura, incidencias y nuevas funciones necesitan responsabilidades explícitas.
- Reserva capacidad de iteración. El uso del MVP debe servir para decidir dónde invertir después.
Fuentes y referencias
Las fuentes respaldan el método de validación, las comprobaciones de permisos y el precio de infraestructura citado. El desglose y la recomendación son criterios editoriales; el ejemplo económico es hipotético. Consultadas el 5 de noviembre de 2026.
El siguiente paso
Define qué debe poder completar tu primer usuario y qué necesitas aprender de esa prueba. En Apogeo podemos ayudarte a delimitar el desarrollo de producto digital. Cuéntanos el recorrido, las conexiones y tu presupuesto disponible para valorar una primera versión concreta.
