Guía de desarrollo de aplicaciones: costes, plazos y problemas habituales

Empiece por determinar si necesita una app

La decisión más costosa sobre una app se toma antes de escribir cualquier línea de código: si debe construirse en absoluto.

Una app debe encontrarse en una tienda, instalarse, concedérsele permisos y luego mantenerse en la pantalla de inicio, que su propietario limpia periódicamente. Eso es mucha fricción para superar. Vale la pena cuando la app ofrece algo que una página web no puede:

• Capacidad offline — personal de campo, repartidores, cualquier lugar con señal poco fiable
• Notificaciones push — las útiles de verdad, no los mensajes publicitarios
• Hardware del dispositivo — flujos de cámara, periféricos Bluetooth, ubicación en segundo plano
• Uso de alta frecuencia — algo que se abre casi a diario, donde ahorrar tres segundos se acumula

Si ninguno de esos casos aplica, una página web móvil rápida y bien construida llegará a más gente por menos dinero. Se lo decimos a los clientes con frecuencia, y suele ser lo más valioso que se dice en la primera llamada.

¿Cuánto cuesta realmente una app en el Reino Unido?

Los "calculadores de costes de apps" publicados son herramientas de marketing. Estos son los rangos que nosotros cotizamos, para una agencia del Reino Unido que hace bien el trabajo:

Alcance	Rango típico
Plataforma única, conjunto de funciones enfocado	£6,000 – £12,000
Multiplataforma, iOS y Android	£8,800 – £18,000
Con pagos, datos en tiempo real o sincronización offline	£14,000 – £28,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 mayor cada año. Google eleva su requisito de API objetivo anualmente y retira las apps que quedan atrás. Una app sin presupuesto de mantenimiento tiene una vida útil de aproximadamente dos años.

Cualquier cosa cotizada por menos de £3,200 es bien un template de marca blanca, o un precio fijo que se renegociará una vez aparezcan las partes complicadas.

Nativo o multiplataforma

Esta es la decisión que más afecta al coste, así que vale la pena ser claro sobre el equilibrio en lugar de tratarla como un tema de preferencia personal.

Multiplataforma (Flutter, React Native) significa una única base de código que genera ambas aplicaciones. Ahorras aproximadamente un 30–40% en el desarrollo y mucho más a largo plazo, ya que solo hay un conjunto de funciones que mantener sincronizadas en lugar de dos. Para la gran mayoría de aplicaciones empresariales —reservas, pedidos, tableros, herramientas internas—, el usuario no notará la diferencia.

Nativo (Swift, Kotlin) implica dos bases de código y dos conjuntos de experiencia en plataformas. Es la mejor opción cuando la aplicación 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 sea visible.

La segunda pregunta es quién lo mantiene. Si tu equipo ya trabaja con React, React Native les permite compartir habilidades y algo de código con tu aplicación web, lo que suele compensar la ventaja técnica de Flutter. Si no tienes capacidad móvil interna en absoluto, Flutter es la apuesta técnica más segura. De cualquier manera, el mercado laboral al que recurrirás para contratar importa más que cualquier benchmark.

¿Dónde desaparecen silenciosamente los presupuestos

Cinco factores explican la mayoría de los sobrecostes que vemos en proyectos que llegan de otros lugares.

1. Comportamiento offline tratado como un caso marginal

"Necesita funcionar sin conexión" suena como una característica. Es una arquitectura. Incorporar almacenamiento local y resolución de conflictos en una aplicación construida alrededor de llamadas API en vivo es casi como hacer un rediseño desde cero. 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, terminan siendo "envía el mismo mensaje a todos", lo que lleva a los usuarios a desactivarlas —perdiendo el mecanismo de retención para el que se construyó la aplicación.

3. Revisión de la tienda no planificada

Las primeras presentaciones a Apple suelen ser rechazadas. No por algo dramático: cadenas de privacidad, términos de suscripción poco claros, falta de eliminación de cuenta, presentación en iPad para una aplicación universal. Un calendario sin margen para una o dos rondas de revisión es un calendario que se retrasará públicamente.

4. Backend considerado como un pensamiento posterior

La mayoría de las aplicaciones son una interfaz 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 una web y necesita ajustes para móvil —puntos finales más conversacionales, paginación y cargas útiles optimizadas para conexión móvil.

5. Pruebas realizadas solo en un dispositivo insignia

Esto es principalmente un problema de Android, y uno grande. Una aplicación que funciona bien en un dispositivo insignia reciente puede ser inutilizable en un terminal de gama media, que es el que lleva un porcentaje significativo de usuarios del Reino Unido. Sumando los gestores de batería de los fabricantes que matan procesos en segundo plano, "las notificaciones dejaron de funcionar" se convierte en tu ticket de soporte más común.

Cronograma realista

Para una aplicación empresarial multiplataforma:

1. Definición y diseño — 3 a 4 semanas. Lista de funciones, flujos e interfaz revisados en dispositivos reales.
2. Desarrollo principal — 8 a 12 semanas en ciclos de dos semanas, cada uno finalizando con una versión instalable.
3. Beta — 2 semanas con usuarios reales en TestFlight y pruebas internas de Play.
4. Solicitud a la tienda — 1 a 3 semanas, incluyendo rondas de revisión probables.
5. Post-lanzamiento — 30 días de correcciones, luego mantenimiento.

Aproximadamente cuatro a cinco meses. Comprimirlo suele implicar eliminar la fase beta, que es exactamente la parte que detecta los problemas que, de otro modo, tus usuarios reportarían públicamente en las reseñas de la tienda.

¿Qué preguntar a cualquier agencia antes de firmar

• ¿Quién es el propietario del código y recibiremos el repositorio?
• ¿Las cuentas de desarrollador están registradas a nuestro nombre o al de ustedes?
• ¿Qué ocurre si Apple rechaza la presentación — ¿se factura?
• ¿Cuál es el costo anual de mantenimiento, por escrito?
• ¿En qué dispositivos específicos probarán?
• ¿Qué ocurre con la aplicación si dejamos de trabajar juntos?

Las respuestas a estas seis preguntas te dicen más que cualquier portafolio. Si alguna de ellas genera duda, esa es tu respuesta.

Próximos pasos

Si estás evaluando una aplicación, la primera conversación útil no debe girar en torno a las funciones, sino en si la aplicación tiene la forma adecuada para resolver el problema. Nos encantaría tener esa conversación y decirte si la solución es una web.