"¿Cuánto cuesta hacernos una app?" es de las preguntas que más recibimos de empresas de Madrid, y también de las que peor se responden con una cifra única, porque debajo de la palabra "app" caben proyectos que van desde 1.200 euros hasta más de 60.000, con decisiones técnicas de por medio que cambian radicalmente el resultado final. Aquí está el desglose real, sin la respuesta genérica de "depende" sin más contexto detrás.
Lo primero: probablemente no necesitas una app nativa
Antes de hablar de precios, hay una confusión que hace que muchos presupuestos salgan disparados desde el principio: pensar que "app" significa automáticamente una aplicación nativa publicada en App Store y Google Play. Una app nativa exige, en la mayoría de los casos, dos desarrollos separados (uno para iOS, otro para Android), cada uno con su propio lenguaje, sus propias reglas de publicación y su propio ciclo de mantenimiento. Eso no es solo el doble de coste inicial, es el doble de coste cada vez que hay que actualizar algo.
La alternativa que cubre la inmensa mayoría de casos de negocio en Madrid es la PWA, aplicación web progresiva: se instala en el móvil igual que una app nativa, funciona sin conexión para las partes que lo necesiten, envía notificaciones push y accede a cámara o geolocalización, pero es un único desarrollo que funciona en cualquier dispositivo con navegador, sin pasar por las tiendas de aplicaciones ni sus comisiones. Para un sistema de reservas, un portal de cliente o un panel interno de gestión, que es lo que necesita la mayoría de pymes de Madrid, una PWA bien construida resuelve exactamente lo mismo que una app nativa a una fracción del coste de desarrollo y mantenimiento.
Los rangos reales por tipo de proyecto
Como referencia orientativa, y siempre sujeta a un taller de descubrimiento que ajuste la cifra a tu caso concreto, estos son los rangos habituales según el tipo de proyecto:
Un módulo de gestión sencillo, con una o dos funcionalidades y una o dos integraciones con sistemas existentes, suele partir de 2.500 euros. Es el caso típico de "necesito que esta parte de mi proceso deje de hacerse a mano en un Excel". Una plataforma media, con varios usuarios, área privada, facturación integrada y entre tres y cinco integraciones, se mueve habitualmente entre 6.000 y 15.000 euros. Una plataforma compleja, con múltiples roles de usuario, API pública, arquitectura multi-tenant, pagos integrados y pensada para escalar a muchos usuarios simultáneos, puede superar los 15.000 euros y llegar a 60.000 o más según el alcance.
Fuera de estos tres escalones generales, hay proyectos con un perfil propio: un ERP o sistema de gestión interna a medida suele partir de 8.000 euros; una PWA instalable con funcionalidades de app nativa (offline, push, cámara) desde 5.000 euros; un middleware de integración entre sistemas existentes desde 2.500 euros; automatización técnica pura (scripts, bots, pipelines de datos) desde 1.200 euros; y un portal con áreas privadas y control de roles desde 4.500 euros. Ninguna de estas cifras es una tarifa cerrada de catálogo, todas son puntos de partida orientativos que se ajustan tras entender el caso real.
El factor que más dispara el presupuesto (y no es el diseño)
Es habitual pensar que lo que más encarece un proyecto es la complejidad visual: cuántas pantallas, cuántos colores, cuántas animaciones. En la práctica, el factor que más dispara el presupuesto real es el número de integraciones con sistemas externos. Conectar tu aplicación con un ERP, una pasarela de pago, un sistema de logística o un marketplace no es solo "unir dos cajas", implica entender cómo funciona el sistema ajeno, gestionar sus límites de tasa de peticiones, manejar los casos en los que ese sistema falla o responde con datos inesperados, y probar todo eso de forma exhaustiva antes de que llegue a producción.
Un proyecto con una interfaz visualmente sencilla pero cinco integraciones complejas casi siempre cuesta más que un proyecto con una interfaz vistosa pero sin ninguna integración externa. Al pedir presupuesto, vale la pena hacer una lista honesta de con qué sistemas necesita hablar tu aplicación desde el primer día, porque es la pregunta que más cambia la cifra final, más que cualquier decisión de diseño.
Por qué el código y el repositorio deben ser siempre tuyos
Un punto que no es exactamente de precio pero que afecta directamente al coste real a largo plazo: el código de tu aplicación debería quedar siempre en un repositorio de tu propiedad, sea GitHub, GitLab o Bitbucket, dentro de tu propia organización, no en la cuenta personal del desarrollador o de la agencia. Esto no es un detalle técnico menor, es lo que determina si tu aplicación es un activo tuyo o una dependencia perpetua de un proveedor concreto.
Si el código no es tuyo desde el primer commit, cambiar de proveedor en el futuro implica empezar de cero, perdiendo todo el trabajo ya pagado. Con el código en tu propio repositorio, documentación técnica y diagramas de arquitectura entregados al finalizar, siempre puedes llevarte el proyecto a otro equipo si lo necesitas, lo que además te da mejor posición negociadora con tu proveedor actual sobre precios de mantenimiento futuro.
Mantenimiento: la partida que casi nadie presupuesta bien
El desarrollo inicial de una aplicación tiene fecha de entrega y presupuesto cerrado, pero una aplicación en producción necesita mantenimiento continuo: actualizaciones de seguridad de las dependencias que usa, monitorización para detectar errores antes de que los reporte un usuario enfadado, copias de seguridad periódicas y horas de soporte para ajustes menores. Este coste suele quedar fuera del presupuesto inicial y se factura aparte, habitualmente desde unos 150 euros al mes para proyectos de tamaño pyme, con horas de desarrollo incluidas cada mes.
Un error común es no preguntar por esta partida al pedir presupuesto y descubrirla después del lanzamiento, cuando ya no hay margen para comparar condiciones. Pregunta siempre, en la misma reunión donde se habla del coste de desarrollo, cuánto cuesta el mantenimiento posterior y qué incluye exactamente, porque es un compromiso que dura mucho más tiempo que el propio proyecto de desarrollo.
Cuándo tiene sentido empezar pequeño y crecer después
No todos los proyectos necesitan lanzarse con el alcance completo desde el primer día. Una estrategia razonable, sobre todo cuando el presupuesto es limitado o cuando no está del todo claro qué funcionalidades usará más la gente, es lanzar primero una versión mínima que resuelva el problema más urgente, medir el uso real con usuarios reales, y ampliar después con datos concretos en vez de intentar adivinar todo el alcance desde una reunión inicial.
Esto solo funciona bien si la arquitectura técnica desde el primer día está pensada para crecer sin tener que rehacer la base: una base de datos bien diseñada, una API modular, código limpio y documentado. Un proyecto lanzado con prisa y sin esa base sólida suele necesitar una reescritura completa en cuanto intenta crecer, lo que termina costando más que haberlo hecho bien desde el principio. Preguntar explícitamente cómo se plantea la arquitectura de cara a un crecimiento futuro es una buena señal de si el equipo que va a construir tu proyecto piensa a medio plazo o solo en entregar y cobrar.
Qué preguntar antes de pedir presupuesto en Madrid
Antes de pedir presupuesto a cualquier empresa de desarrollo en Madrid, prepara respuestas claras a estas preguntas, porque son exactamente las que determinan la cifra final: qué sistemas externos necesita conectar tu aplicación desde el primer día, cuántos usuarios distintos con roles diferentes van a usarla, si necesitas funcionalidad offline o notificaciones push, y cuál es tu horizonte de crecimiento en los próximos doce meses. Cuanto más claras tengas estas respuestas, más ajustado y realista será el presupuesto que recibas, y menos sorpresas de coste aparecerán a mitad de proyecto.
Y desconfía de cualquier presupuesto cerrado que se dé sin un taller de descubrimiento previo: un proyecto de cierta complejidad no se puede presupuestar con precisión en una llamada de quince minutos, y quien lo hace así está adivinando, no calculando, por muy segura que suene la cifra que te den al teléfono.
PWA frente a app nativa, comparadas punto por punto
Vale la pena desglosar la comparación entre PWA y app nativa más allá del titular de "es más barata", porque cada punto concreto tiene una razón técnica detrás que ayuda a decidir con criterio propio en vez de fiarte de lo que te cuente cada proveedor.
En cuanto a coste de desarrollo, una PWA es un único código base que funciona en cualquier dispositivo con navegador (móvil, tablet, ordenador), mientras que una app nativa completa normalmente exige dos bases de código separadas, una en Swift o Kotlin para iOS y otra distinta para Android, cada una mantenida por su cuenta. En cuanto a distribución, una PWA se instala directamente desde el navegador sin pasar por ningún proceso de revisión externo, mientras que una app nativa depende de que Apple o Google aprueben cada actualización, un proceso que puede tardar días y que en ocasiones rechaza cambios por motivos poco predecibles.
En cuanto a actualizaciones, una PWA se actualiza al instante para todos los usuarios en cuanto se despliega el cambio en el servidor, sin que nadie tenga que descargar nada manualmente; una app nativa depende de que cada usuario actualice desde la tienda, lo que en la práctica significa que durante semanas hay usuarios usando versiones distintas y potencialmente con bugs ya corregidos en la versión nueva. En cuanto a acceso a hardware, aquí es donde la app nativa gana con claridad: sensores muy específicos, Bluetooth de bajo nivel o integraciones profundas con el sistema operativo siguen siendo terreno casi exclusivo de la app nativa, aunque cada año las PWA ganan más capacidades en este terreno.
En cuanto a descubrimiento, si tu modelo de negocio depende de que la gente encuentre tu app buscando en la tienda de aplicaciones (un juego, una app de consumo masivo), la presencia en App Store y Play Store aporta un canal de captación que una PWA no tiene por definición. Pero si tus usuarios llegan a la aplicación desde tu propia web, un enlace de WhatsApp o una campaña de marketing, ese argumento pierde peso casi por completo, porque nadie va a buscarte en la tienda si ya sabe dónde encontrarte.
Un ejemplo real de decisión: sistema de reservas para un negocio de servicios
Para hacer esto más concreto, pensemos en un caso habitual entre empresas de Madrid: un negocio de servicios (una clínica, una asesoría, un centro de estética) que quiere que sus clientes puedan reservar cita desde el móvil sin llamar por teléfono. La tentación inicial suele ser pedir "una app" sin más especificar, y la primera pregunta que hacemos siempre es qué necesita hacer esa aplicación exactamente: ver disponibilidad, elegir hora, recibir confirmación, quizás pagar por adelantado o recibir un recordatorio automático el día antes.
Ninguna de esas funcionalidades requiere acceso a hardware específico del móvil ni depende de que el usuario la descubra buscando en una tienda de aplicaciones: el cliente llega desde la web del negocio, desde un enlace en redes sociales o desde una tarjeta con un código QR. Es exactamente el perfil de proyecto donde una PWA resuelve el cien por cien de la necesidad real a una fracción del coste y del tiempo de desarrollo de una app nativa equivalente, con notificaciones push para el recordatorio de cita incluidas sin necesidad de pasar por ninguna tienda de aplicaciones.
Cómo se reparte el presupuesto dentro de un proyecto típico
Para entender mejor en qué se va el dinero de un proyecto de desarrollo, ayuda ver cómo se reparte habitualmente el presupuesto entre las distintas fases del trabajo. El descubrimiento y diseño técnico (entender el problema real, definir el alcance, diseñar la arquitectura y el modelo de datos) suele representar entre un 15 y un 20% del presupuesto total, y es la fase que más impacto tiene en evitar sobrecostes después, porque un problema mal entendido al principio se paga muchas veces más caro corregirlo a mitad de desarrollo que detectarlo antes de escribir una sola línea de código.
El desarrollo en sí, tanto de la interfaz visible como de la lógica de negocio en el servidor, suele ser la partida más grande, entre un 45 y un 55% del total. Las integraciones con sistemas externos, cuando las hay, pueden representar entre un 15 y un 30% adicional dependiendo de cuántas sean y de la calidad de la documentación que ofrezca cada sistema externo (una API bien documentada de un proveedor serio cuesta mucho menos integrar que un sistema legado sin documentación real). El resto, entre un 10 y un 15%, se reparte entre pruebas, despliegue y la formación al equipo que va a usar la aplicación una vez lanzada.
Conocer este reparto ayuda a entender por qué un proyecto "solo un poco más complejo" en apariencia puede costar bastante más de lo esperado: normalmente no es la parte visible la que crece, es el trabajo de fondo en integraciones y lógica de negocio que no se ve en una maqueta pero que determina si la aplicación funciona de verdad en producción.
En resumen
El coste de desarrollar una aplicación para tu empresa en Madrid va desde 1.200 euros para automatización técnica sencilla hasta más de 60.000 euros para plataformas complejas multi-tenant, y en la mayoría de los casos una PWA (aplicación web instalable) cubre lo mismo que una app nativa a una fracción del coste. El factor que más dispara el presupuesto son las integraciones con sistemas externos, no el diseño visual. El código y el repositorio deben ser siempre tuyos, y el mantenimiento posterior es una partida aparte que conviene preguntar desde la primera reunión.
Presupuesto cerrado frente a presupuesto por horas: qué conviene según el proyecto
Otra decisión que afecta al coste final, aunque menos hablada que el tipo de aplicación, es el modelo de facturación del propio desarrollo. Un presupuesto cerrado fija de antemano el alcance completo y el precio total, y tiene la ventaja de la previsibilidad: sabes exactamente cuánto vas a pagar antes de empezar. Su contrapartida es que cualquier cambio de alcance a mitad de proyecto, por pequeño que parezca, suele generar una negociación adicional, porque el precio original se calculó sobre un alcance concreto que ya no es el mismo.
El modelo de bolsa de horas, en cambio, factura el tiempo real dedicado dentro de un paquete de horas contratado, y encaja mejor con proyectos donde el alcance todavía no está del todo definido o donde se espera iterar bastante según lo que se vaya aprendiendo con usuarios reales. La contrapartida aquí es la previsibilidad inversa: es más difícil saber de antemano el coste total, aunque suele compensarse con mayor flexibilidad para ajustar prioridades semana a semana sin renegociar un contrato completo.
Para un proyecto con alcance claro desde el principio (por ejemplo, digitalizar un proceso concreto y bien entendido), el presupuesto cerrado suele ser la opción más cómoda. Para un proyecto más exploratorio, donde el propio negocio todavía está decidiendo qué necesita exactamente, la bolsa de horas con revisión de prioridades cada pocas semanas suele dar mejor resultado, porque evita pagar por un alcance cerrado que probablemente cambiará antes de terminar.
Errores de presupuesto que se repiten en proyectos de empresas de Madrid
Después de trabajar con negocios de distintos tamaños en Madrid, hay un patrón de errores de presupuesto que se repite con la frecuencia suficiente como para merecer mención aparte. El primero es no incluir el mantenimiento en el cálculo total del primer año: comparar solo el coste de desarrollo entre dos proveedores sin preguntar por el coste de mantenimiento mensual da una imagen incompleta, porque un desarrollo más barato con un mantenimiento mensual caro puede salir más costoso a doce meses que uno más caro de entrada con mantenimiento razonable.
El segundo error habitual es subestimar el número real de integraciones necesarias en la reunión inicial, normalmente porque nadie ha hecho el ejercicio de listar explícitamente con qué sistemas debe hablar la nueva aplicación hasta que el desarrollo ya está en marcha y aparece una integración "que se nos había olvidado mencionar". El tercer error es no preguntar quién es el propietario del código y del repositorio antes de firmar, lo que puede convertir a la empresa en rehén de un único proveedor para cualquier cambio futuro, con el poder de negociación que eso le da a ese proveedor sobre el precio de cualquier trabajo posterior.
Qué significa realmente un "taller de descubrimiento"
Es un término que aparece mucho en presupuestos serios de desarrollo, y vale la pena explicar qué debería incluir de verdad, porque no todos los que usan la frase hacen lo mismo. Un taller de descubrimiento real, de entre dos y cuatro horas, debería cubrir al menos: entender el problema de negocio concreto que se quiere resolver (no solo la funcionalidad que se imagina el cliente, sino el problema real detrás), mapear los sistemas existentes con los que la nueva aplicación necesitará hablar, identificar quién va a usar la aplicación y con qué frecuencia, y acordar un primer boceto de alcance que sirva de base para el presupuesto cerrado.
Si un proveedor te da un presupuesto cerrado sin haber dedicado ese tiempo a entender tu caso concreto, esa cifra es, en el mejor de los casos, una estimación aproximada basada en proyectos parecidos que ha hecho antes, no un cálculo real sobre tu situación. Puede acabar siendo correcta por casualidad, pero el riesgo de que el alcance real termine siendo distinto al presupuestado es mucho mayor que cuando sí ha habido ese trabajo previo de entendimiento.
Si quieres una estimación real para tu proyecto, hacemos un taller de descubrimiento sin coste dentro de nuestro servicio de desarrollo de apps en Madrid, con presupuesto cerrado en 24 horas y sin la respuesta genérica de "depende" que probablemente ya has escuchado varias veces antes de llegar hasta aquí.