Te mandaron tres presupuestos para tu MVP y la diferencia entre el más barato y el más caro es de 10x — y ninguno te explica por qué.
Eso pasa todo el tiempo. No porque alguien esté mintiendo, sino porque "un MVP" puede ser muchas cosas distintas, y cada estudio cotiza su propia interpretación de lo que vos describiste en una reunión de 45 minutos. El problema no es el precio: es que nadie desglosó qué variables lo mueven.
Qué es lo que realmente se está cotizando
Antes de mirar cualquier número, vale aclarar algo: un MVP no es tu producto completo a mitad de precio. Es la versión más acotada que te permite probar una hipótesis concreta con usuarios reales. Cuando alguien te cotiza USD 60.000 para un MVP, casi siempre está cotizando otra cosa — un producto completo, con todos los casos borde resueltos, pensado para escalar desde el día uno.
Lo primero que un equipo serio tiene que hacer con vos es acotar el scope. No adivinar: acotar. Eso solo ya reduce la varianza en el presupuesto.
Las variables que más mueven el precio
El tipo de producto. No es lo mismo una app de gestión interna para un equipo de 10 personas que una plataforma de marketplace con dos tipos de usuario. La complejidad del flujo principal es el primer multiplicador.
Las integraciones. Pagos, geolocalización, carga de documentos, envío de mails transaccionales, conexión con un ERP existente — cada integración suma tiempo real de desarrollo y testing. Pensemos en un founder que quiere lanzar una app de turnos médicos: si además necesita integrarse con la historia clínica del sanatorio, eso puede duplicar el tiempo de la primera versión. No es una estimación: es geometría del proyecto.
El stack y quién lo mantiene. Algunas tecnologías son más rápidas para arrancar pero más caras de mantener o escalar. Otras tienen más curva al principio y te ahorran reescrituras después. El stack correcto depende del caso; no existe una respuesta universal.
El equipo real detrás del presupuesto. Un freelance solo, una agencia con subcontratistas, un equipo dedicado — cada modelo tiene costos de coordinación distintos y riesgos distintos. El freelance puede ser más barato en papel y dejarte a mitad de camino. La agencia grande puede cobrar reuniones y slides que no necesitás. El equipo dedicado de tamaño medio suele ser donde mejor relación costo-riesgo encontrás para un MVP.
El ritmo de entrega. Dos semanas de desarrollo intensivo con un equipo que no trabaja nada más cuestan distinto que el mismo volumen de trabajo distribuido en dos meses. La velocidad tiene un precio, y eso está bien — lo importante es saberlo de entrada.
Rangos reales por categoría de proyecto
Estos son rangos orientativos para el mercado argentino, con equipos de desarrollo locales, en 2024-2025. No son cotizaciones: son puntos de referencia para que llegués a una conversación de presupuesto con contexto.
Validación de concepto (Validate): Si lo que necesitás es probar el flujo principal con usuarios reales — una sola pantalla de carga, autenticación básica, el core de la propuesta de valor — estás en el orden de USD 3.900 con precio fijo. Dos semanas. Sin sorpresas.
MVP para mostrar a usuarios o inversores (Launch): Un producto con más pantallas, dos o tres integraciones, flujo completo de onboarding y un panel básico de administración. Acá el rango empieza en USD 8.000 y puede llegar a USD 20.000 según la complejidad real del scope, en ocho semanas.
Escala o segunda versión (Scale): Ya tenés algo funcionando y querés agregarle capas: más usuarios, más integraciones, reportes, roles. Desde USD 15.000, con timeline que depende del estado del código base.
De prototipo hecho con IA a producción: Armaste algo en Lovable, Bolt o Bubble y anda en la demo, pero necesitás que aguante usuarios reales. El trabajo es evaluar qué rescatar y qué reescribir. Desde USD 6.000, dependiendo de qué tan lejos del límite está el prototipo original.
Por qué la diferencia de 10x entre presupuestos
Cuando recibís un presupuesto muy bajo, casi siempre falta algo: el testing, el deploy, las revisiones, el tiempo de coordinación, o directamente parte del scope que el developer asumió que no ibas a pedir. Cuando recibís uno muy alto, casi siempre sobra algo: pantallas que no necesitás en la primera versión, arquitectura pensada para cuando tengas 100.000 usuarios, o simplemente el margen de una agencia grande que tiene mucha estructura propia.
La clave no es quedarte con el del medio por descarte. La clave es poder comparar presupuestos que cotizaron lo mismo. Y eso solo pasa cuando el scope está escrito.
Cómo acotar el scope antes de cotizar
Lo que hacemos antes de dar un número es una sesión de definición de producto. Preguntamos qué hipótesis querés probar, quién es el usuario de la primera versión, cuál es el flujo que tiene que funcionar sí o sí, y qué podría entrar en una segunda iteración. Con eso armamos una propuesta con precio fijo y fecha de entrega por escrito — en 24 horas.
No cobramos esa sesión. No porque seamos generosos: porque sin esa conversación cualquier número que demos es una adivinanza.
El código queda en tu GitHub desde el primer día. Hacemos una demo todos los viernes. Y si no llegamos a la fecha acordada, seguimos hasta terminar sin costo adicional. Esas tres cosas deberían ser el piso de cualquier conversación de presupuesto, no un diferencial.
Lo que vale comparar antes de decidir
Cuando tengas varios presupuestos sobre la mesa, fijate en esto: ¿El scope está escrito en detalle o es una descripción general? ¿El precio es fijo o por hora? ¿Hay una fecha de entrega comprometida o una estimación? ¿El código es tuyo desde el día uno?
Si alguna de esas preguntas no tiene respuesta clara en el presupuesto, no es que te estén ocultando algo necesariamente — puede ser que todavía no lo definieron. Y eso es exactamente lo que conviene resolver antes de firmar cualquier cosa.