Empiece por si necesita una app
La decisión más cara sobre una app se toma antes de que exista código alguno: construirla o no.
Una app debe encontrarse en una tienda, instalarse, conceder permisos y luego mantenerse en una pantalla de inicio que su dueño limpia periódicamente. Eso es mucha fricción que superar. Vale la pena superarla cuando la app ofrece algo que un sitio web no puede:
- Capacidad offline — personal de campo, repartidores, cualquier lugar con señal poco fiable
- Notificaciones push — realmente útiles, no emisiones de marketing
- Hardware del dispositivo — flujos de cámara, periféricos Bluetooth, ubicación en segundo plano
- Uso de alta frecuencia — algo que se abre casi todos los días, donde ahorrar tres segundos se acumula
Si nada de esto aplica, un sitio web móvil rápido y bien construido llegará a más personas por menos dinero. Se lo decimos a los clientes con regularidad, y suele ser lo más valioso que se dice en una primera llamada.
¿Cuánto cuesta realmente una app en el Reino Unido?
Los "calculadores de coste de app" publicados son herramientas de marketing. Estos son los rangos en los que trabajamos en una agencia del Reino Unido que hace el trabajo correctamente:
| Alcance | Rango típico |
|---|---|
| Plataforma única, conjunto de funciones enfocado | £15,000 – £30,000 |
| Multiplataforma, iOS y Android | £22,000 – £45,000 |
| Con pagos, datos en tiempo real o sincronización offline | £35,000 – £70,000 |
| Mantenimiento continuo, por año | 15–20% del coste de desarrollo |
Esa última fila es la que la mayoría de los presupuestos omiten, y no es opcional. iOS y Android lanzan una versión principal cada año. Google eleva su requisito de API objetivo anualmente y elimina apps que se quedan atrás. Una app sin presupuesto de mantenimiento tiene una vida útil de aproximadamente dos años.
Todo lo que se cotice por debajo de £8,000 es o bien una plantilla genérica, o bien un precio fijo que se renegociará cuando surjan las partes complicadas.
Nativa o multiplataforma
Esta es la decisión que más afecta al coste, por lo que conviene aclarar el equilibrio en lugar de tratarla como un tema de preferencia.
Multiplataforma (Flutter, React Native) significa una única base de código que genera ambas apps. Ahorras aproximadamente un 30–40% en desarrollo y considerablemente más con el tiempo, ya que solo hay un conjunto de funciones que mantener sincronizado en lugar de dos. Para la gran mayoría de apps empresariales —reservas, pedidos, paneles de control, herramientas internas— el usuario no nota la diferencia.
Nativa (Swift, Kotlin) implica dos bases de código y dos conjuntos de conocimientos especializados en plataformas. Es la opción correcta cuando la app depende en gran medida del dispositivo: procesamiento sostenido de cámara, seguimiento de ubicación en segundo plano, ARKit o animaciones lo suficientemente complejas como para que una capa de renderizado intermedia resulte visible.
La segunda pregunta es quién se encargará del mantenimiento. Si tu equipo ya trabaja con React, React Native les permite compartir habilidades y parte del código con tu app web, lo que suele compensar la ventaja técnica de Flutter. Si no tienes capacidad móvil interna, Flutter es la apuesta técnica más segura. En cualquier caso, el mercado laboral al que recurrirás para contratar importa más que el benchmark.
Dónde los presupuestos desaparecen en silencio
Cinco aspectos son responsables de la mayoría de los sobrecostes que vemos en proyectos que llegan de otras empresas.
1. Comportamiento offline tratado como un caso excepcional
"Necesita funcionar sin conexión" suena como una función. Es una arquitectura. Incorporar almacenamiento local y resolución de conflictos en una app construida alrededor de llamadas API en tiempo real se acerca a una reescritura. Decide esto en la primera semana.
2. Notificaciones push añadidas al final
Las notificaciones requieren infraestructura de servidor, flujos de permisos, segmentación y enlaces profundos que abran la pantalla correcta. Si se añaden al final, acaban siendo "enviar el mismo mensaje a todos", lo que enseña a los usuarios a desactivarlas —perdiendo la herramienta de retención para la que se construyó la app.
3. Revisión en la tienda no planificada
Las primeras presentaciones a Apple suelen rechazarse. No por algo grave: cadenas de privacidad, términos de suscripción poco claros, falta de opción para eliminar la cuenta, presentación en iPad de una app universal. Un calendario sin margen para una o dos rondas de revisión es un calendario que retrasará la publicación de forma pública.
4. Backend considerado como un pensamiento posterior
La mayoría de las apps son un frontend para un servicio. Si ese servicio no existe, estás encargando dos proyectos. Cuando el backend ya existe, su API suele estar diseñada para un sitio web y necesita reajustarse para móvil: endpoints más conversacionales, paginación y cargas útiles optimizadas para una conexión móvil.
5. Pruebas solo en un dispositivo insignia
Esto es, sobre todo, un problema de Android, y grave. Una app que funciona bien en un dispositivo insignia reciente puede ser inusable en el teléfono de gama media que usan muchos usuarios en el Reino Unido. Si sumamos los gestores de batería de los fabricantes que matan procesos en segundo plano, "las notificaciones dejaron de funcionar" se convierte en el ticket de soporte más común.
Cronograma realista
Para una app empresarial multiplataforma:
- Definición de alcance y diseño — 3 a 4 semanas. Lista de funciones, flujos y diseño de interfaz revisados en dispositivos reales.
- Desarrollo principal — 8 a 12 semanas en ciclos de dos semanas, cada uno finalizando con una versión instalable.
- Beta — 2 semanas con usuarios reales en TestFlight y pruebas internas de Play.
- Presentación en la tienda — 1 a 3 semanas, incluyendo los posibles ciclos de revisión.
- Post-lanzamiento — 30 días de correcciones, luego mantenimiento.
Unos cuatro o cinco meses en total. Comprimirlo suele significar eliminar la fase beta, que es precisamente la que detecta los problemas que tus usuarios reportarían públicamente en las reseñas de la tienda.
Qué preguntar a cualquier agencia antes de firmar
- ¿Quién es dueño del código y recibimos el repositorio?
- ¿Los cuentas de desarrollador están registradas a nuestro nombre o al vuestro?
- Si Apple rechaza la presentación, ¿se factura?
- ¿Cuál es el coste anual de mantenimiento, por escrito?
- ¿En qué dispositivos específicos se probará la app?
- ¿Qué ocurre con la app si dejamos de trabajar juntos?
Las respuestas a estas seis preguntas te dicen más que cualquier portfolio. Si alguna genera dudas, esa es tu respuesta.
Próximos pasos
Si estás evaluando una app, la primera conversación útil no es sobre funciones, sino sobre si la app es la solución adecuada para el problema. Estamos encantados de mantener esa conversación y decirte si la respuesta es un sitio web.
Preguntas frecuentes
Una aplicación enfocada en una sola plataforma suele costar entre £15,000 y £30,000. Una solución multiplataforma para iOS y Android ronda entre £22,000 y £45,000, dependiendo de la cantidad de trabajo backend necesario. Las aplicaciones con pagos, datos en tiempo real o sincronización offline se sitúan en el extremo superior. Cualquier presupuesto inferior a £8,000 suele corresponder a una plantilla con tu logo.
De 12 a 20 semanas desde la aprobación del alcance hasta el primer lanzamiento para la mayoría de aplicaciones empresariales, más una a tres semanas para la revisión en la tienda. La mayor variable no es la velocidad de desarrollo, sino la rapidez con la que el cliente toma decisiones y proporciona el contenido necesario.
Para la mayoría de aplicaciones empresariales, el enfoque multiplataforma con Flutter o React Native es la mejor opción y ahorra entre un 30% y un 40% frente a desarrollar dos apps separadas. Optar por nativo vale la pena cuando se depende de funciones avanzadas del dispositivo, como procesamiento avanzado de cámara, ubicación en segundo plano o animaciones complejas continuas.
Normalmente no. Si tus usuarios visitan tu servicio una vez al mes, un sitio web móvil rápido les servirá mejor y costará mucho menos: nadie instala una app que usa ocasionalmente. Una app justifica su existencia cuando necesita acceso offline, notificaciones push, hardware del dispositivo o uso realmente frecuente.
- desarrollo de aplicaciones
- mobile
- budgeting
- iOS
- Android