¿Cuánto cuesta crear una app? Lo que te presupuestan y lo que pagas después

¿De qué depende el coste de crear una app?

El precio de una app no depende del número de pantallas. Depende de las piezas que tienen que funcionar cuando nadie mira: quién puede leer qué datos, cómo se cobra, qué pasa sin cobertura y cómo se comporta la app en un móvil de gama baja con un Android antiguo.

• Plataformas. Android, iOS, web o las tres. Con Flutter se comparte casi todo el código: Tajo, la app de control horario para obra que diseñamos y construimos con Grupo Edma, funciona en Android y en web sin una sola línea de Kotlin propio, y Pax tiene unas 120, solo para el widget de la pantalla de inicio. Aun así, cada tienda tiene su cuenta, su revisión y sus normas, como explicamos en Flutter o nativo para la app de tu empresa.
• Servidor. Si hay cuentas de usuario, datos compartidos o pagos, hay un backend que diseñar, proteger y pagar cada mes.
• Pagos. Una suscripción no es solo un botón. Hay que verificar la compra en el servidor, gestionar renovaciones y cancelaciones y cumplir las políticas de pagos de la tienda.
• Integraciones. Inicio de sesión con Google o Apple, notificaciones, anuncios, IA. Cada librería trae dependencias que luego hay que mantener.
• Quién la hace. Cambia cómo se reparte el trabajo y, sobre todo, quién responde cuando algo se rompe.

Con IA, con un freelance o con una agencia: ¿qué cambia en la factura?

Las tres vías pueden acabar en una app publicada. Lo que cambia es en qué se va el dinero y qué parte del trabajo se queda sin hacer.

Con IA

Herramientas como Lovable, Bolt o Cursor abaratan mucho llegar a una primera versión que se ve bien. No abaratan lo que no se ve: reglas de seguridad, compras verificadas, fallos que solo salen en ciertos móviles. Ese trabajo aparece más tarde y suele llegar sin presupuesto. Hasta dónde llega cada herramienta lo contamos en Lovable, Bolt, v0, Replit o Cursor: hasta dónde llegan, y por qué estas apps fallan en producción, en las 9 causas.

Con un freelance

Hablas directamente con quien programa, y eso evita malentendidos. El riesgo está en la continuidad. Si el proyecto se queda a medias, necesitas tener a tu nombre el repositorio, las cuentas de las tiendas, las claves de firma y el acceso al servidor. Si no los tienes, quien llegue después empezará cobrándote por averiguar qué hay.

Con una agencia

Hay más gente y más proceso, y eso se paga. A cambio, debería haber pruebas, documentación y alguien que responda. Pregunta quién va a programar tu app de verdad y si el presupuesto llega hasta la publicación en la tienda o se queda en «entregamos el código».

¿Qué se paga después de publicar la app?

Esto es lo que casi ningún presupuesto de desarrollo incluye y lo que vas a pagar de todos modos. Las cifras son a fecha de octubre de 2026.

• Cuenta de Google Play: una cuota de registro de US$25 de pago único. Google avisa de que no se devuelve si los datos de identidad resultan no válidos.
• Apple Developer Program: 99 dólares de cuota anual. Al ser anual, entra en el presupuesto de todos los años, no solo del primero.
• Servidor: Firebase tiene un plan sin coste (Spark) y otro de pago por uso (Blaze), y el segundo incluye las cuotas gratuitas del primero. En Cloud Firestore, lo gratuito son 50K lecturas y 20K escrituras de documentos al día. Cloud Functions no se puede usar en Spark: hay que pasar a Blaze. Allí no solo se pagan las invocaciones (2M al mes sin coste y, a partir de ahí, $0.40 por millón): según la página de precios de Firebase, también se paga el tiempo de cómputo (400K GB-segundos y 200K CPU-segundos al mes sin coste; después, tarifas de Google Cloud) y el tráfico de salida (5 GB al mes sin coste y luego $0.12/GB). La misma página incluye Cloud Build (120 minutos al día sin coste y luego $0.003/min) y el almacenamiento de contenedores en Artifact Registry (500 MB sin coste; después, tarifas de Google Cloud).
• Comisión de la tienda: Google Play y la App Store se quedan un porcentaje de cada venta dentro de la app. Lo vemos en el siguiente apartado.
• Mantenimiento: actualizar librerías, adaptarse a las nuevas versiones de Android e iOS y arreglar lo que esos cambios rompen. No es opcional.

El servidor es el coste más traicionero porque no es fijo. Una pantalla que lee la misma colección cada vez que se abre no se nota con diez usuarios, pero con mil puede disparar la factura. Por eso conviene medir el consumo antes de lanzar, no cuando llega el cargo.

¿Cuánto se queda Google Play de cada suscripción?

Según la página oficial de tasas de servicio de Google Play, en el Espacio Económico Europeo (España incluida), el Reino Unido y Estados Unidos, las suscripciones con renovación automática pagan una tasa de servicio del 10 % más una tarifa de facturación del 5 % (la tabla de Google sitúa el 10 % en la fila del primer millón de dólares de ingresos anuales y no fija otro porcentaje por encima). Ese esquema separa las instalaciones nuevas de las existentes con la fecha del 30 de junio de 2026, pero a las suscripciones les aplica el mismo porcentaje en los dos casos.

En los mercados a los que aún no ha llegado el esquema nuevo, la misma página de Google Play fija un 15 % para las suscripciones con renovación automática. En el resto de compras, el 15 % solo cubre el primer millón de dólares al año y exige estar inscrito en ese nivel; por encima, la comisión es del 30 %.

Este apartado detalla sobre todo la comisión de Google Play. Si publicas también en iOS, Apple tiene su propio esquema. En la Unión Europea, según su página sobre apps en la UE, desde el 1 de octubre de 2026 la comisión estándar de las ventas que pasan por su sistema de compras dentro de la app es del 26 %. Baja al 15 % en dos casos: si estás en el App Store Small Business Program y en las suscripciones con renovación automática a partir de su primer año, estés o no en ese programa. Para entrar en el programa hay que inscribirse, y cubre a quien no superó el millón de dólares de ingresos el año natural anterior. Si lo superas durante el año, a las ventas siguientes se les aplica la comisión estándar. En una suscripción, por tanto, el primer año pagas el 26 % si no estás inscrito, y a partir del segundo, el 15 % sin hacer nada.

Las actualizaciones obligatorias que rompen cosas

Una app no está terminada el día que sale en la tienda. Las librerías de las que depende siguen cambiando, y algunas versiones rompen la compatibilidad a propósito.

Un ejemplo: la versión 7.0.0 de firebase_remote_config, etiquetada el 15 de octubre de 2026, avisa de que trae cambios incompatibles. En Android pasa a usar Firebase BoM 35 y exige minSdk 24. En Apple sube el SDK de Firebase para iOS a la 13.0.0 y pide macOS 11 para los paquetes Swift.

En la práctica, si tu app admitía móviles con un Android anterior al 7.0 (API 24, el minSdk que exige esa versión), esos móviles dejarán de recibir las versiones nuevas en cuanto actualices. Además, los paquetes de FlutterFire comparten el núcleo de Firebase, así que actualizar uno suele obligar a actualizar los demás: autenticación, base de datos, notificaciones. Cada salto de estos son horas o días de trabajo con pruebas, y alguien tiene que pagarlos.

Con el sistema operativo pasa lo mismo. Las versiones recientes de Android exigen un permiso para programar una alarma exacta que antes no hacía falta. Una app que no lo pide compila igual, pero el recordatorio no suena.

Dónde se fue el trabajo al llevar Pax a Google Play

Pax es nuestra app de estoicismo diario: un proverbio de los clásicos cada día y un ritual de reflexión nocturna guiado por un mentor con IA. Está publicada en Google Play. No vamos a darte la cifra en euros ni en horas. Sí te contamos dónde se fue el trabajo, que es lo que ningún presupuesto de desarrollo recoge.

Por debajo de todo eso está la suscripción Pax Plus, que se verifica en el servidor y no en el móvil, y Pax tuvo que pasar la revisión de Google Play y cumplir sus políticas de pagos. Nada de esto es una pantalla, y todo es trabajo. Si vas a publicar en Google Play, empieza por la prueba cerrada y sus requisitos.

¿Qué cambia con un presupuesto cerrado?

Un presupuesto cerrado fija el precio y el alcance antes de empezar. Por sí solo no abarata la app. Lo que hace es obligar a decidir de antemano qué entra y qué no, y deja el riesgo de las horas de más en manos de quien construye.

En PlisPlas trabajamos así, tanto en apps nuevas como en proyectos que ya existen: presupuesto cerrado antes de la primera línea de código. Si el proyecto ya existe, antes hacemos una auditoría por escrito que dice qué se queda, qué se tira y cuánto cuesta cada opción. Sin eso, cualquier precio es una apuesta.

Para que un presupuesto cerrado valga lo que promete, comprueba que incluye esto:

• La publicación en las tiendas, no solo la entrega del código.
• La verificación de los pagos en el servidor, si hay compras o suscripciones.
• Las reglas de seguridad del servidor, con sus pruebas, y comprobado que esas pruebas se ejecutan de verdad. En una auditoría de Tajo vimos que el paso de CI que debía ejecutar los tests de reglas de Firestore no los ejecutaba: más de 200 tests que nunca habían llegado a correr.
• Pruebas en móviles reales, no solo en el emulador. En Tajo, el dictado del parte se perdía en silencio si el reconocedor se paraba tras unos segundos sin voz, y se vio con un micrófono real.
• Quién paga las cuotas de las tiendas y el servidor, y a nombre de quién quedan las cuentas.
• Qué pasa con las actualizaciones obligatorias después del lanzamiento.

¿Por qué el 20 % que falta es donde se dispara la factura?

El 80 % se ve en una demo: pantallas, navegación, datos de ejemplo. El 20 % no aparece hasta que hay usuarios reales, dinero real y una revisión que puede rechazar la app. Sale caro porque se descubre tarde, cuando ya hay código encima que da por hecho que esa parte funciona.

Por eso un mismo proyecto puede costar muy distinto según cuándo alguien revise la seguridad o los pagos. Si tu app ya está a medias, la pregunta deja de ser cuánto cuesta crearla y pasa a ser si conviene arreglarla o rehacerla.

Si empiezas de cero, en PlisPlas también hacemos apps nuevas con presupuesto cerrado antes de la primera línea de código, con ese 20 % dentro desde el principio. Si tienes un proyecto atascado, lo empezara una IA, un freelance o una agencia, en Relevo lo retomamos siempre con el mismo proceso: auditoría por escrito (qué se queda, qué se tira y cuánto cuesta cada opción) y presupuesto cerrado antes de tocar una línea. En los dos casos, escríbenos a info@enunplisplas.com.

Preguntas frecuentes sobre el coste de crear una app

Fuentes

1. Registrarse en una cuenta de desarrollador de Google Play — Ayuda de Play Console · consultado el 20 de octubre de 2026
2. Service fees — Ayuda de Play Console · consultado el 20 de octubre de 2026
3. Apple Developer Program — Apple Developer · consultado el 20 de octubre de 2026
4. App Store Small Business Program — Apple Developer · consultado el 20 de octubre de 2026
5. Update on apps distributed in the European Union — Apple Developer · consultado el 20 de octubre de 2026
6. Firebase Pricing — Firebase · consultado el 20 de octubre de 2026
7. firebase_remote_config-v7.0.0 — FlutterFire en GitHub · consultado el 20 de octubre de 2026