Qué determina realmente el coste de una app móvil

«Cuánto cuesta desarrollar una app móvil» es una de las búsquedas más frecuentes alrededor del desarrollo de software, y también una de las que peor responde una cifra suelta. Dos ideas descritas con la misma frase en un primer correo —«una app para reservar citas», por ejemplo— pueden ser proyectos con un alcance completamente distinto según lo que hay detrás de esa frase.

Antes de hablar de coste, conviene separar dos cosas que se mezclan constantemente: escribir el código de la aplicación, y todo lo que rodea a esa aplicación para que funcione de verdad en las manos de un usuario real. La segunda parte es la que casi nunca aparece en un presupuesto improvisado, y suele ser la que más pesa.

El código es solo una parte del proyecto

Una aplicación que llega de verdad a la App Store y a Google Play necesita ficha de tienda, capturas de pantalla, un proceso de revisión que cada plataforma gestiona a su manera, y —en cuanto vende algo— una infraestructura de suscripción o compra que funcione de forma fiable. Quien no cuenta esto desde el principio se lleva la sorpresa justo antes del lanzamiento previsto, normalmente cuando ya hay una fecha de marketing o una presentación comprometida que no se puede mover.

Esto no afecta solo a startups con una idea de producto. Empresas ya establecidas piden apps como complemento a un negocio existente —una tarjeta de fidelización, una herramienta de reservas, un acceso a un portal que hasta ahora solo funcionaba en el navegador— con la misma frecuencia, y las preguntas que determinan el proyecto son casi siempre las mismas.

Lo que realmente mueve el número

Una base de código o dos equipos separados. Construimos apps móviles con Flutter: una sola base de código para iOS y Android, en lugar de dos equipos manteniendo dos versiones con sus propios errores. Eso mantiene el tiempo de desarrollo más predecible, y sobre todo significa que un cambio no se hace, se prueba y se olvida dos veces.

Cuántos roles de usuario maneja. Una app de consumo con un único tipo de usuario es más simple que una que además tiene un panel de administración, roles internos o niveles de acceso distintos.

Si necesita cuenta de usuario y backend propio. Una app que solo muestra contenido estático es mucho más contenida que una que gestiona sesiones, guarda datos de usuario y necesita un sistema detrás que responda en tiempo real.

Si vende algo dentro de la app. En cuanto hay una compra o una suscripción, entra en juego la infraestructura de pagos recurrentes, la gestión de renovaciones y cancelaciones, y las reglas específicas de cada tienda de aplicaciones — otra capa de trabajo que no está en el diseño de pantallas, pero que determina si la app genera ingresos de forma fiable o genera tickets de soporte.

Cuántas integraciones necesita. Una app aislada, que no necesita hablar con ningún otro sistema, es la más barata de construir porque sus límites están completamente bajo control. Una app que tiene que leer o escribir en un ERP, un CRM o una pasarela de pago depende de lo que ese otro sistema realmente ofrece.

Factor	Qué cambia
Número de roles de usuario	Complejidad del modelo de datos y de las pruebas
Cuenta de usuario y backend	Necesidad de un sistema propio detrás de la app
Compras o suscripciones dentro de la app	Infraestructura de pagos recurrentes, reglas de tienda
Integraciones con sistemas existentes	Tiempo de análisis, gestión de errores
Publicación en iOS y Android	Dos procesos de revisión distintos, un solo código con Flutter

El lanzamiento no es el final del proyecto

Una app publicada necesita mantenimiento: nuevas versiones de iOS y Android que rompen algo sin avisar, cambios en las políticas de las tiendas, corrección de errores que solo aparecen con uso real. Un presupuesto que solo cubre “hasta publicar en la tienda” no es un presupuesto completo — es la primera fase de uno más largo.

Lo que no vamos a hacer

No vamos a dar un número en esta página, por la misma razón que no lo damos en ninguna otra: cualquier cifra dada antes de conocer el alcance real es una estimación disfrazada de presupuesto. Lo que sí podemos anticipar es cómo trabajamos: entrega de software utilizable cada pocas semanas, para revisar pantallas reales en lugar de una maqueta, y detectar una decisión equivocada pronto en lugar de tarde.

Por dónde empezamos nosotros

Antes de dar cualquier cifra preguntamos qué hace la app, cuántos tipos de usuario tiene, si vende algo dentro de la aplicación, y con qué sistemas necesita hablar. Esas cuatro respuestas determinan la forma del proyecto mucho más que cualquier rango publicado en un blog. Puede ver ejemplos de apps que hemos construido, incluidos productos propios, en la página de trabajo realizado, o leer más sobre nuestro enfoque de aplicaciones móviles.

El precio de una app no está en el código que se ve en pantalla. Está en todo lo que hace falta para que ese código llegue de forma fiable a un usuario real.

Si el proyecto que tiene en mente pasa además por una ayuda pública, el artículo sobre Kit Digital y software a medida explica qué conviene verificar antes de encajar el proyecto en una categoría. Para lo demás, una conversación sobre el alcance real es más rápida que seguir buscando un rango de precios.