Respuesta corta: conmigo, un MVP de alcance acotado cuesta 1.900–9.300 € netos a precio cerrado y lleva de 2 a 6 semanas. Una web de marketing o una landing más sencilla cuesta 1.500–3.500 €. Los productos mayores los divido en fases en lugar de presentar un único presupuesto enorme, de modo que usted paga sucesivamente por partes que funcionan y están listas para desplegarse, no por una promesa.
Esa es mi respuesta. La más larga y sincera es esta: a la pregunta «cuánto cuesta un MVP» no hay una respuesta universal, porque el precio no lo fija la tecnología, sino cómo se define el alcance. Este artículo explica de dónde vienen las grandes diferencias entre presupuestos, qué incluye realmente un proyecto dentro de este rango y cómo reducir costes sin reducir las opciones del producto.
Por qué los presupuestos de un MVP van de 5.000 € a cifras de seis dígitos
Pida presupuesto de un «MVP» a cinco proveedores y puede recibir cinco cifras que se diferencian entre 10 y 50 veces. No tiene por qué significar que alguien mienta. Cada uno puede haber presupuestado un producto distinto.
La definición del alcance es el producto real. «Una aplicación en la que los usuarios reservan citas» suena a una sola frase, pero cada pregunta de detalle añade un buen trozo de trabajo:
- Inicio de sesión: ¿solo correo y contraseña, o Google/Apple, restablecimiento de contraseña, verificación del correo?
- Pagos: ¿un único checkout de Stripe, o suscripciones, devoluciones, facturas, IVA?
- Roles: ¿un solo tipo de usuario, o clientes + proveedores del servicio + administradores, cada uno con una vista distinta?
- Panel de administración: ¿gestiona los datos directamente en la base de datos, o necesita una interfaz para una persona no técnica?
- Integraciones: sincronización de calendario, SMS, CRM, contabilidad; cada una es un miniproyecto aparte.
- Móvil: ¿web adaptable, o aplicaciones nativas en dos tiendas con dos procesos de revisión?
Cada «sí» puede añadir más días de trabajo. El proveedor que asume solo «síes» presupuesta una plataforma. El que asume solo «noes», un prototipo. Ambos pueden llamarlo «su MVP».
Quién presupuesta también cambia la cifra:
- Las agencias presupuestan equipos. La oferta de una agencia puede incluir gestión de proyecto, diseño, varios desarrolladores y QA, porque el equipo es su unidad de venta. Usted paga esa estructura, que puede costar al mes más que todo un MVP de alcance acotado hecho por un solo especialista.
- Las plataformas de freelancers presupuestan horas. La facturación por horas puede parecer barata por unidad, pero sin tope el total queda abierto: cuanto más dura el trabajo, más paga.
- Los proveedores a precio cerrado presupuestan el resultado. Alcance por escrito, precio, plazo. El riesgo de estimar el alcance acordado recae en el proveedor. Así trabajo yo, y es el modelo que yo mismo elegiría como comprador.
Antes de comparar cifras, compare para qué son. Un presupuesto de 5.000 € y uno de 50.000 € normalmente no son ofertas competidoras: son productos distintos con el mismo nombre.
Qué incluye realmente un MVP de 1.900–9.300 €
La honestidad exige trazar este límite con claridad, así que aquí va.
Un MVP de alcance acotado al precio de partida suele incluir:
- Un flujo clave construido bien de principio a fin: por ejemplo, el usuario se registra, hace esa única cosa que el producto promete y paga por ella
- Una interfaz limpia y adaptable (no una plantilla tirada sobre la mesa, pero tampoco un diseño de autor de agencia)
- Inicio de sesión básico, si el flujo lo requiere
- Una vía de pago (por ejemplo, checkout o suscripción de Stripe)
- Una forma sencilla de que usted vea los datos y pueda gestionarlos
- Despliegue, dominio, SSL: el producto vive en internet, no «funciona en mi equipo»
- Analítica conectada, para que pueda aprender de verdad tras el lanzamiento
Lo que suele pasar el proyecto a fases:
- Varios roles de usuario con paneles distintos (lo clásico: marketplaces)
- Funciones en tiempo real: chat, actualizaciones en vivo, infraestructura de notificaciones
- Integraciones complejas (ERP, API bancarias, sistemas médicos, todo lo que tenga una capa de cumplimiento normativo)
- Aplicaciones móviles nativas
- Lógica personalizada pesada: algoritmos de emparejamiento, motores de horarios, calculadoras de precios con muchos casos límite
Nada de esto significa «imposible»; significa que se divide. La fase uno lanza en pocas semanas la pieza más arriesgada y más valiosa; cada siguiente se presupuesta solo cuando la anterior funciona y le enseña algo. Nunca paga por adelantado el cuarto mes a partir de conjeturas del mes cero.
Si su idea cabe en la variante de alcance acotado, la oferta de MVP está aquí, con la descripción del proceso.
La mayor palanca de coste: construir para el supuesto más arriesgado
Los fundadores suelen centrarse en negociar la tarifa. Una palanca de coste mayor puede ser lo que decida construir primero: lo más pequeño que pone a prueba el supuesto más arriesgado.
En muchos productos conviene comprobar pronto no solo «¿se puede construir?», sino sobre todo «¿alguien pagará?». Se puede hacer antes de financiar el producto completo:
- Landing + botón de pago real: describa el producto y reúna preventas o anticipos reales. Que nadie pulse «pagar» es motivo para comprobar si la aplicación completa merece ya financiación. Una landing puede estar lista en pocos días al precio de partida de ese tipo de página.
- MVP de un solo flujo: una acción clave, hecha de verdad, con pagos reales. Es el territorio de los 5.000 € en adelante.
- Plataforma completa: roles, administración, integraciones, móvil. Se justifica solo después de que el flujo clave tenga usuarios que pagan, porque entonces construye para una demanda medida, no imaginada.
El error más caro que veo: saltar directamente al nivel tres. Medio año y un presupuesto serio después, el fundador descubre algo que una prueba de dos semanas con una landing habría mostrado por una fracción del dinero. Recortar el alcance no es conformarse con menos: es comprar el mismo conocimiento más rápido y más barato.
Un ejercicio útil antes de cualquier presupuesto: escriba la frase que necesita oír de un cliente («sí, pagaré X €/mes por esto»). Después pregunte cuál es la construcción mínima tras la cual un cliente real podría decirla. Ese es su MVP. Todo lo demás es la fase dos.
Prototipos con IA: barato para empezar, caro para llevarlos a producción
En 2026 puede tener un prototipo con aspecto de funcionar hecho con Lovable, v0 o Bolt en una tarde, a veces por el precio de una suscripción. Eso ha cambiado de verdad la fase inicial, y merece una valoración sincera en lugar de bombo o desprecio.
Cuándo basta un prototipo con IA:
- Enseñar a inversores o a los primeros clientes de qué se trata, visualmente
- Comprobar si el concepto de interfaz tiene sentido antes de comprometerse con él
- Demos internas y maquetas clicables
- Validar el interés antes de cualquier construcción real
Dónde suele quedarse corto:
- Usuarios reales. Los prototipos que funcionan para un probador amable se caen con usuarios simultáneos, datos erróneos y casos límite que nadie pidió en los prompts.
- Pagos. Cobrar dinero real implica webhooks, gestión de pagos fallidos, devoluciones e impuestos: la parte que las herramientas de IA omiten porque el camino feliz de la demo funciona sin ella.
- Seguridad y datos. Un inicio de sesión que de verdad proteja las cuentas, permisos que de verdad limiten el acceso, una base de datos que no se filtre. El código generado suele parecer correcto, y no lo es.
- Cambios. La décima iteración sobre código generado es el momento en que el ritmo se hunde: nadie, ni siquiera la IA, entiende ya del todo lo que hay ahí.
La trampa no es empezar con un prototipo de IA, que suele ser sensato. La trampa es confundirlo con un producto y descubrir el hueco solo después de anunciar la fecha de lanzamiento. Si ya tiene un prototipo que le ha llevado hasta aquí pero no irá más allá, esa es exactamente la situación que cubre AI prototype to production: conservamos lo validado y reconstruimos lo que debe soportar usuarios reales y dinero real.
En el presupuesto, trate el prototipo como parte del gasto de validación, no de construcción. Ayuda a responder a «¿merece la pena construirlo?»; llevar el producto a funcionar requiere un alcance y un presupuesto aparte.
Costes ocultos que olvidan los fundadores
El precio de construcción no es el precio total. Cada uno de estos costes suele ser pequeño por sí solo, pero descubrirlos uno a uno tras el lanzamiento puede convertir un «precio cerrado» en un mal recuerdo. Póngalos en la hoja de cálculo desde el principio:
- Alojamiento. Un MVP inicial típico funciona barato en plataformas modernas (al principio, a menudo casi gratis), pero es una partida recurrente y crece con el uso.
- Dominio y correo. El dominio en sí es barato; el correo profesional con su dominio es un pequeño coste mensual que se olvida de forma rutinaria.
- API externas. Los pagos se llevan un porcentaje de cada transacción. Mapas, SMS, envío de correos, API de IA: todo se cobra por uso. Con el volumen de un MVP está bien, pero deben estar en la lista porque escalan con el éxito.
- Mantenimiento. Las dependencias y los parches de seguridad requieren actualizaciones, y los primeros usuarios reales pueden encontrar problemas que ninguna prueba detectó. Un producto no es una compra única; exige una dedicación continua.
Cómo lo resuelvo yo: el alcance por escrito que recibe antes de pagar nada incluye los costes de mantenimiento previstos, indicados expresamente, con cifras, y las cuentas están a su nombre: alojamiento, dominio, proveedor de pagos, todo. La infraestructura y el código son suyos desde el primer día, así que cambiar de desarrollador no significa perder el producto. Tras el lanzamiento usted elige: mantiene el producto por su cuenta (es su código documentado) o firma un contrato de mantenimiento con un alcance definido. Las condiciones de ambas opciones se fijan de antemano.
Preguntas que hacer antes de pagar a nadie
Hable conmigo o con cualquier otro, estas preguntas separan a los profesionales de las lecciones caras:
- «¿Qué incluye exactamente el precio, por escrito?» Un alcance que cabe en un SMS crecerá en la factura. Insista en una lista escrita de lo que habrá y, igual de importante, de lo que no.
- «¿Precio cerrado o estimación?» Una «estimación» es una cifra que crece. Pregunte quién asume el exceso si el trabajo se alarga.
- «¿Cuándo veré software funcionando?» ¿Una demo semanal de un producto real o una gran presentación al final? Las grandes presentaciones son donde mueren los presupuestos.
- «¿Quién es el propietario del código y de las cuentas?» Repositorio, alojamiento, dominio: ¿a nombre de quién? «Nuestro hasta el último pago» es una correa.
- «¿Y después del lanzamiento?» ¿Cuánto cuesta corregir un error? ¿Cuál es el tiempo de respuesta cuando algo se cae un sábado?
- «¿Puedo hablar con alguien para quien haya lanzado algo?» El portfolio se puede maquillar. Una conversación de quince minutos con un antiguo cliente, no.
La irritación o las evasivas ante estas preguntas son una señal de alarma.
Cómo es el proceso conmigo
Para que quede claro, esto es exactamente lo que ocurre cuando trabajamos juntos; es la lista de comprobación anterior con las respuestas:
- Conversación gratuita de 20 minutos. Usted describe la idea; yo le digo con sinceridad si cabe en un MVP de alcance acotado o requiere fases, incluido el caso en que la respuesta honesta sea «primero pruébelo con una landing».
- Alcance, precio y plazo cerrados por escrito. Antes de que se mueva nada de dinero, tiene un documento: qué se construirá, cuánto cuesta, cuándo estará listo. Si algo no está en el documento y usted lo quiere, es una ampliación presupuestada, no una sorpresa.
- Demo semanal. Cada semana ve un producto que funciona, no diapositivas sobre él. Los cambios de rumbo se hacen mientras son baratos.
- Todo es suyo. Código en su repositorio, infraestructura en sus cuentas, desde el principio.
- Respuesta normalmente en 2 horas. Durante la construcción y después. Trabaja con quien escribe el código: más de 12 años creando productos web, 150+ proyectos, base en Varsovia, fundadores de la UE y de fuera.
Verifique el supuesto más arriesgado antes de financiar el producto completo
Un MVP en 2026 puede costar desde 5.000 € hasta cifras de seis dígitos, y buena parte de la diferencia viene del alcance y del modelo de ejecución. (La escalera completa, del no-code hecho por usted mismo a un equipo enterprise, con los factores de coste y las formas de controlarlos, la describe el artículo coste del desarrollo web según el presupuesto.) El enfoque sensato consiste en definir el proyecto más pequeño que ponga a prueba el supuesto más arriesgado, desplegarlo y usar los datos de usuarios reales para decidir qué merece financiarse en la segunda fase.
Si quiere una cifra real para su idea en lugar de rangos: reserve una conversación gratuita de 20 minutos. Saldrá con una respuesta concreta: un presupuesto cerrado, un plan por fases o un sincero «pruebe esto primero de forma más barata».