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é.
Artículos relacionados
Preguntas frecuentes
Las dudas más comunes. Si la tuya no está, pregúntanos
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.