Cómo calcular el presupuesto de una app a medida sin sorpresas

Antes de pedirme una cifra, hablemos de qué quieres construir. Llevo más de doscientos proyectos cerrados y te puedo asegurar una cosa: la pregunta «¿cuánto cuesta una app?» nunca tiene una respuesta limpia el primer día. Y cuando alguien te la da, desconfía.

Estimar software es adivinar con disciplina. No es magia ni intuición. Es un proceso. El Standish Group lleva décadas publicando lo mismo: alrededor del 66 % de los proyectos de software se pasan de presupuesto, y un 33 % se pasa por encima del 50 %. Esos números bajan en picado cuando hay método y cuando cliente y equipo hablan el mismo idioma. De eso va esta guía: de cómo calcular el presupuesto de una app a medida sin sorpresas y, sobre todo, de qué decisiones tomar para que la cifra final se parezca a la inicial.

Qué hace que una app cueste lo que cuesta

El alcance funcional manda

El precio lo marca lo que la app tiene que hacer. Punto. No es lo mismo un panel interno con cuatro formularios que una plataforma con pagos, geolocalización en tiempo real, visión por ordenador y modo offline. Cuando alguien me pide una cifra rápida, lo primero que hago es clasificar el proyecto en uno de tres cajones:

• App sencilla (gestión de contenido, formularios, listados, panel de administración básico): entre 15.000 y 40.000 euros.
• App de complejidad media (autenticación avanzada, integraciones con APIs externas, notificaciones push, dashboards con analítica): entre 40.000 y 100.000 euros.
• App compleja (pagos, marketplaces, geolocalización, procesamiento de datos en tiempo real, machine learning, múltiples roles de usuario): entre 100.000 y 300.000 euros o más.

Estas horquillas son del mercado español en 2026, hablando de equipos profesionales con experiencia contrastada. No de freelance esporádico ni de fábricas de software offshore. Si te ofrecen mucho menos, lo que han entendido del proyecto no es lo que tú crees que les has contado.

Nativo, híbrido o web: decisión cara

La elección de plataforma cambia la factura. Una app nativa en iOS y Android, desarrollada por separado, puede duplicar el coste de una solución multiplataforma con React Native o Flutter. La PWA es otra ruta válida cuando no necesitas todo el hardware del dispositivo.

No hay respuesta correcta en abstracto. La pregunta sensata es: ¿qué necesita hacer tu producto y qué usuarios tienes? A partir de ahí elegimos. Si te dicen «nosotros siempre hacemos Flutter», pregúntate por qué.

Diseño UX/UI: el que se intenta recortar siempre

El diseño suele llevarse entre el 15 % y el 25 % del presupuesto total. Y es donde más veces he visto a clientes intentar tijeretazos. Mal sitio.

Una app mal diseñada se paga después: en soporte, en formación, en usuarios que la abren una vez y no vuelven. He visto productos técnicamente impecables morirse porque nadie quería usarlos. El diseño no es decoración, es la diferencia entre adopción y silencio.

Infraestructura: lo que casi nadie cuenta el primer día

Hosting, certificados, servicios cloud, bases de datos, monitorización. Costes recurrentes que muchas estimaciones iniciales se saltan y que luego aparecen como sorpresa desagradable. Según escala, hablamos de entre 100 y 5.000 euros al mes.

Mi regla: lo metemos en el presupuesto desde el día uno, proyectado a 12-24 meses. Si no, no es un presupuesto, es una foto a medias.

Mantenimiento: la app no se acaba el día del go-live

Una app es un producto vivo. Sistema operativo nuevo, librería deprecada, bug que aparece, funcionalidad que pide marketing. El mantenimiento anual ronda entre el 15 % y el 25 % del coste inicial. Un proyecto de 80.000 euros necesitará entre 12.000 y 20.000 euros al año para no convertirse en deuda técnica.

Si nadie te habla de esto en la propuesta, te están vendiendo media verdad.

Métodos de estimación que uso en reuniones reales

Puntos de historia

En proyectos ágiles asignamos puntos a cada user story según complejidad, incertidumbre y esfuerzo. Luego se convierten en horas usando la velocidad histórica del equipo. Funciona bien cuando el equipo ya lleva kilómetros juntos. Con equipos nuevos, la velocidad es una hipótesis hasta que sprint a sprint se calibra.

Descomposición funcional detallada

Trocear cada funcionalidad en tareas técnicas concretas (modelo de datos, API, frontend, testing, despliegue) y estimar una por una. Es el método más fino y también el más caro de producir. Lo reservo para proyectos grandes o cuando el cliente necesita un precio cerrado de verdad.

Estimación por analogía

Si el equipo ha hecho cosas parecidas antes, los datos reales de esos proyectos son la mejor base. Ajustas por alcance, complejidad y stack. Las cifras son sorprendentemente fiables cuando la analogía es honesta. Cuando no lo es, te engañas a ti mismo.

Cómo evitar que el presupuesto se rompa

Empieza por un MVP, no por el producto soñado

El error que más me cuesta desactivar en una primera reunión: querer presupuestar la versión definitiva. Identifica lo mínimo que demuestra valor (el MVP) y presupuesta solo eso. Cuando esté en la calle y los usuarios te digan qué falta, las siguientes iteraciones se presupuestan con información real, no con suposiciones.

He visto proyectos de 200.000 euros que tendrían que haber sido tres apuestas de 60.000 cada una. Tres veces más aprendizaje, tres veces menos riesgo.

Documenta el alcance, en serio

Las desviaciones casi nunca son por estimaciones flojas. Son por cambios de alcance no gestionados. Requisitos funcionales bien escritos, criterios de aceptación claros, y un proceso formal de gestión de cambios. Esa es la palanca.

Si quieres profundizar, nuestra guía sobre cómo redactar requisitos funcionales para un proyecto web o app cuenta el proceso entero.

Elige el modelo de contratación que toca

Hay dos modelos base y un híbrido que cada vez uso más:

• Precio cerrado (fixed price): el proveedor asume el riesgo a cambio de un precio fijo. Necesita un alcance perfectamente definido y deja poco margen para cambios.
• Time & materials (T&M): se factura por horas dedicadas. Máxima flexibilidad para iterar, pero pide a cambio control fino del cliente.
• T&M con cap: la flexibilidad del T&M con un techo de gasto acordado. Reparte el riesgo de forma más sana.

No hay modelo mejor en abstracto. Hay modelo adecuado para tu nivel de claridad de alcance y tu tolerancia al riesgo.

Margen de contingencia: entre el 15 % y el 25 %

Toda estimación profesional debería llevar un colchón de entre el 15 % y el 25 %. No es permiso para gastar más. Es lo que absorbe los imprevistos técnicos, los pequeños cambios de alcance y las complejidades que ningún equipo veía venir el día de la firma. Los presupuestos que no lo incluyen se desvían casi siempre. Casi.

Reporting semanal, sin excepciones

El equipo debería darte informes periódicos, idealmente semanales, con avance frente a presupuesto consumido. Jira, Asana, Linear, lo que sea, pero con burndown visible. Las desviaciones se detectan pronto o se sufren tarde. No hay un punto medio cómodo.

Banderas rojas en un presupuesto

Desconfía si ves alguno de estos síntomas:

• Cifra redonda sin desglose. Un presupuesto serio detalla coste por módulo, fase o funcionalidad.
• Precio muy por debajo del mercado. Si tres proveedores te piden entre 60.000 y 80.000 euros y uno ofrece 20.000, el alcance que están leyendo no es el mismo.
• Sin partida de infraestructura ni mantenimiento. Solo el desarrollo inicial es media foto.
• Sin fase de descubrimiento. Presupuestar sin entender el negocio es una receta para la desviación.
• Plazo irreal. Un proyecto de 80.000 euros no se entrega en un mes con dos personas. Las matemáticas tienen que cuadrar.

Cualquiera de estos puntos, por sí solo, no te dice nada. Varios juntos, sí.

El presupuesto es una herramienta de decisión, no un número

Lo digo en cada kick-off: el presupuesto no es la cifra del final del PDF. Es el documento que te ayuda a decidir qué entra, qué sale, qué se aplaza y con qué tecnología. Una buena estimación transforma la incertidumbre en un mapa de decisiones.

Si tienes una idea sobre la mesa y quieres una estimación honesta, en Tangram Consulting hacemos un análisis inicial gratuito y te damos cifras desglosadas sin compromiso. Agendemos una sesión de scope y vemos juntos qué proyecto tienes realmente entre manos.

Cómo pedir un presupuesto que no se rompa

Resumiendo lo que pediría yo si estuviera al otro lado de la mesa: desglose por módulos, supuestos explícitos, costes recurrentes proyectados a dos años, margen de contingencia visible, modelo de contratación coherente con tu nivel de definición y reporting semanal pactado por escrito. Si tu proveedor te entrega todo eso, la cifra final se va a parecer mucho a la inicial. Y cuando no se parezca, vais a saber por qué.