Casi todos los artículos que responden a esta pregunta sueltan una cifra de desarrollo, la acompañan de dos rangos y se detienen ahí, como si el gasto terminase el día en que la aplicación aparece en la tienda. En la práctica pasa justo lo contrario, porque una app se parece más a un coche de empresa que a un mueble: hay un precio de compra y hay un coste de tenerla. Por eso aquí vamos a poner precio a la vida entera de la aplicación, desde el primer boceto hasta el quinto año, con la aritmética a la vista para que usted pueda repetirla con sus propias cifras.
Qué está comprando de verdad cuando paga por una aplicación móvil
Cuando un proveedor le entrega un presupuesto por "una app", ese número cubre cinco cosas distintas que conviene nombrar una por una, porque casi todas las discusiones de precio nacen de dar alguna de ellas por supuesta:
- La aplicación de iPhone, es decir, el programa que sus clientes se descargan desde la App Store y que funciona en los teléfonos de Apple.
- La aplicación de Android, el mismo programa escrito para el resto de teléfonos del mercado y publicado en Google Play.
- El backend, que dicho en palabras llanas es un ordenador alquilado en un centro de datos donde viven las cuentas de sus clientes, los pedidos, los mensajes y las fotos. Las dos apps casi no guardan nada dentro del teléfono, se lo piden a ese ordenador cada vez que alguien abre una pantalla.
- El panel de administración, la pantalla de ordenador desde la que su equipo cambia precios, consulta pedidos, contesta a un cliente o bloquea a alguien. Sin ese panel, cada cambio pequeño vuelve a ser un correo al programador y una factura.
- Las dos fichas de tienda, o sea los textos, las capturas y el icono con los que la aplicación se presenta en App Store y en Google Play, más el papeleo que ambas compañías exigen para dejarla publicada.
Con esas cinco piezas encima de la mesa aparece la idea que sostiene todo lo demás: el desarrollo se paga una vez, pero la aplicación se comporta como una suscripción de la que usted es dueño. Los teléfonos y sus sistemas operativos cambian siguiendo un calendario anual fijo, gaste usted o no gaste, así que su app envejece sola aunque nadie toque una sola línea de código.
Este texto está escrito para quien tiene que decidir si gasta o no gasta: el dueño de una clínica, el responsable de una tienda, la persona que dirige una empresa de servicios. No es una comparativa técnica para programadores, y por eso cada cifra va en dinero y en semanas, nunca en unidades que solo entiende quien escribe el código.
En Linkysoft hacemos esta cuenta antes de firmar, y cuando alguien nos pide desarrollar una aplicación móvil lo primero que ponemos por escrito no es el diseño, sino lo que va a costar sostenerla los cinco años siguientes.
Las tres franjas de precio que vemos en la práctica y qué hay dentro de cada una
Los presupuestos reales se agrupan en tres bandas bastante estables, y reconocer en cuál cae su idea le ahorra semanas de reuniones:
- App sencilla, de 8.000 a 25.000 USD, de 6 a 10 semanas. Catálogo, reservas, registro y acceso del usuario, avisos al teléfono y un backend pequeño. Es la app de una peluquería, un gimnasio o una escuela que quiere que sus clientes reserven sin llamar.
- App transaccional, de 25.000 a 70.000 USD, de 3 a 5 meses. Cuentas de cliente, cobros dentro de la aplicación, permisos distintos según el puesto del empleado, un panel de administración de verdad y un comportamiento razonable cuando la cobertura se cae en un sótano o en un ascensor.
- Marketplace o app regulada, de 70.000 a 200.000 USD en adelante, entre 6 y 12 meses. Dos lados de usuarios que hay que equilibrar, seguimiento en vivo sobre un mapa, chat, un registro de auditoría que guarda quién hizo qué y cuándo, y el trabajo de cumplimiento normativo que exige un sector vigilado como la salud o las finanzas.
Queda por explicar algo que desconcierta a todo el mundo: el mismo alcance, escrito en el mismo documento y enviado a cinco empresas, vuelve con presupuestos que se diferencian por tres. La explicación cabe en dos números. Una app de tamaño medio son entre 700 y 1.400 horas de trabajo, y las tarifas del mercado van desde unos 20 a 50 USD la hora en un extremo hasta 90 a 180 USD la hora en el otro. Multiplique usted mismo y verá que lo que cambia entre un presupuesto y otro casi nunca es el talento, sino la veteranía del equipo, la profundidad de las pruebas y quién le contesta el teléfono a las dos de la madrugada cuando los cobros dejan de entrar.
Si prefiere una aritmética que pueda repetir en una servilleta, cuente pantallas. Una pantalla terminada, con su diseño, su versión de iPhone, su versión de Android, su trozo de backend y sus pruebas, sale entre 1.200 y 2.500 USD. Treinta pantallas, que es una app de negocio corriente, aterrizan entre 36.000 y 75.000. Cuando una oferta se queda muy por debajo de esa cuenta suele ser porque falta algo dentro, así que merece la pena entender cómo se arma un presupuesto antes de comparar cifras.
A dónde va el dinero dentro del desarrollo
Cuando repartimos un presupuesto de app, el plan interno se parece siempre a esto:
- Diseño y experiencia de usuario, alrededor del 15 por ciento.
- Las dos aplicaciones, la de iPhone y la de Android, alrededor del 40 por ciento.
- El backend y su panel de administración, alrededor del 20 por ciento.
- Pruebas, alrededor del 13 por ciento.
- Gestión del proyecto, alrededor del 12 por ciento.
Sume las tres últimas líneas y aparece el dato incómodo: cerca de la mitad del dinero compra cosas que su cliente no verá jamás. De ahí nace el recorte más tentador y también el más caro, que es rebajar las pruebas, porque un fallo encontrado después del lanzamiento cuesta varias veces lo que habría costado corregirlo antes, y encima llega acompañado de reseñas de una estrella que se quedan ahí durante meses.
Hay otro motivo por el que las pantallas cuestan más de lo que parece a simple vista. Una pantalla sencilla nunca es una sola pantalla: necesita su estado de carga mientras llegan los datos, su estado vacío para el cliente que todavía no ha hecho ningún pedido, su estado de error para cuando el servidor no contesta y su estado sin conexión para el metro y el aparcamiento subterráneo. Una lista de 30 pantallas son en realidad unos 120 comportamientos distintos que alguien tiene que diseñar, programar y comprobar uno a uno.
Un solo código o dos, y qué le hace esa decisión a la factura
Aquí hay dos caminos y conviene entenderlos sin tecnicismos. El camino nativo consiste en escribir dos aplicaciones separadas, cada una en el lenguaje que prefiere el fabricante del teléfono, de modo que hay dos programas que mantener para siempre. El camino multiplataforma consiste en un único código compartido, normalmente Flutter o React Native, del que salen las dos aplicaciones a la vez.
La diferencia en dinero es clara. Dos apps nativas suman en conjunto entre 1,6 y 1,8 veces el coste de una sola plataforma, porque el diseño y el backend se comparten y no se pagan dos veces. Un desarrollo multiplataforma ahorra normalmente entre un 30 y un 40 por ciento de la factura inicial, y aproximadamente esa misma proporción en cada cambio que pida usted después, que es donde el ahorro se nota de verdad, porque los cambios no terminan nunca.
Dicho esto, hay casos en los que pagar el desarrollo nativo está plenamente justificado: cuando la aplicación exprime la cámara o trabaja con realidad aumentada, cuando tiene que hablar con un aparato por Bluetooth, cuando necesita seguir la ubicación en segundo plano durante toda la jornada, o cuando lo que está construyendo es un juego. Para una app de negocio normal, con su catálogo, sus cuentas y sus cobros, la respuesta correcta es multiplataforma, y así se lo decimos a nuestros clientes aunque el presupuesto salga más bajo.
El ahorro más contundente, sin embargo, es otro: lanzar primero en una sola plataforma recorta la primera factura entre un 35 y un 45 por ciento. La plataforma que elija debe ser la que de verdad llevan sus clientes en el bolsillo, y eso no se decide con estadísticas de país sino con un día detrás del mostrador mirando qué teléfono saca la gente para pagar.
Las facturas pequeñas que nadie mete en el presupuesto
Empecemos por las cuentas de las tiendas, que son baratas pero obligatorias. Apple cobra 99 USD al año por mantener una app publicada, y Google Play cobra 25 USD una sola vez al abrir la cuenta, así que son 124 USD el primer año y 99 USD cada año siguiente. Las dos cuentas tienen que abrirse a nombre de la empresa del cliente y nunca a nombre de la agencia, porque el día que decida cambiar de proveedor la aplicación debe seguir siendo suya sin negociar nada con nadie.
Después vienen los materiales de la ficha, que se olvidan en casi todos los presupuestos y que llevan trabajo real:
- Un icono que se distinga en una pantalla llena de iconos.
- Capturas preparadas para varios tamaños de dispositivo, no una sola imagen estirada.
- Una descripción por cada idioma en el que quiera aparecer.
- Una política de privacidad publicada y accesible.
- Una declaración de seguridad de datos que explique qué recoge la app y para qué.
- Un camino dentro de la propia aplicación para que el usuario borre su cuenta, que es hoy uno de los motivos más frecuentes de rechazo en un primer envío.
Hay también gastos de puesta en marcha que aparecen una vez y sorprenden a todo el mundo: el alta en la pasarela de pagos con su verificación de empresa, que puede llevar días; un dominio y su certificado; unos cuantos teléfonos reales para probar, porque el simulador del programador miente; y la custodia segura de la clave de firma, ese archivo que demuestra ante las tiendas que la aplicación es suya y sin el cual no se puede publicar ni una corrección.
Un apunte que en nuestra región importa mucho: hacer bien el árabe o cualquier otro idioma que se lee de derecha a izquierda añade entre un 15 y un 25 por ciento a las líneas de diseño y pruebas, no al proyecto entero. Planteado desde el principio es un sobrecoste modesto y previsible, mientras que añadirlo cuando la app ya está construida cuesta bastante más y deja costuras visibles.
Cuánto cuesta mantener viva una aplicación durante un año
La regla con la que trabajamos es sencilla: reserve entre un 15 y un 20 por ciento del precio de desarrollo cada año para mantenimiento. Una app de 45.000 USD cuesta por tanto entre 6.750 y 9.000 USD anuales solo para seguir donde está, y eso todavía sin contar el alojamiento.
Conviene entender por qué ese gasto no es opcional. iPhone y Android publican cada uno una versión mayor de su sistema al año, y Apple sube más o menos una vez al año la versión mínima de herramientas con la que se acepta una aplicación, de modo que una app abandonada llega a un punto en el que ni siquiera se puede publicar una corrección de un fallo pequeño sin antes pagar una puesta al día completa. Por experiencia, una aplicación desatendida empieza a romperse de forma visible entre los 18 y los 24 meses.
El alojamiento, en cambio, escala con las personas y no con la ambición del proyecto. Por debajo de unos 5.000 usuarios al mes, lo normal son entre 40 y 150 USD mensuales. Con unos 50.000 usuarios al mes y una app que mueve imágenes y vídeo, la cifra habitual está entre 300 y 800 USD mensuales. Súmele la vigilancia de errores y caídas, que ronda los 50 USD al mes y avisa de un problema antes de que lo haga un cliente enfadado, más las copias de seguridad y una copia de pruebas donde estrenar los cambios antes de que los vea nadie.
Puesto en una sola cuenta, el primer año de una app mediana ya en marcha se reparte así: unos 7.500 USD de mantenimiento y adaptación a los sistemas operativos, unos 3.000 de alojamiento y base de datos, unos 1.800 de servicios externos, unos 600 de vigilancia de errores y 124 de cuentas de tienda, lo que da alrededor de 13.000 USD al año.
Si esta parte le ha sorprendido, no es raro, y es exactamente por eso por lo que insistimos tanto en hablar de el mantenimiento anual antes de firmar el desarrollo y no siete meses después.
Los costes que crecen con sus usuarios, no con su código
Hay una familia de gastos que no depende de lo que construya, sino de cuánta gente use la aplicación, y son los que descolocan a un propietario en el segundo año.
Los códigos de un solo uso enviados por SMS cuestan entre 0,02 y 0,09 USD por mensaje según el país. Con 5.000 accesos al mes y dos mensajes por acceso, eso son entre 200 y 900 USD mensuales solo por dejar entrar a la gente, y por eso el acceso por correo electrónico o mediante una aplicación de códigos suele amortizarse en un trimestre.
Los mapas y el cálculo de rutas también se pagan por uso. Una app de reparto que hace unas 100.000 cargas de mapa al mes acaba pagando habitualmente entre 200 y 700 USD mensuales, una cifra que conviene estimar antes de prometer seguimiento en vivo a todo el mundo.
La comisión de las tiendas merece un párrafo propio porque decide si los cobros deben estar dentro de la app o fuera. Apple y Google se quedan alrededor del 30 por ciento de lo que venda en bienes digitales, alrededor del 15 por ciento si su empresa factura menos de un millón al año en la tienda y también en las suscripciones a partir del segundo año, y nada en absoluto cuando lo que vende son bienes físicos o servicios que se prestan en persona. Compare esa mordida con el coste de cobrar con tarjeta en su propia web, que ronda el 2,9 por ciento más una pequeña cantidad fija por operación, y verá que la decisión de dónde cambia el dinero de manos vale mucho dinero al año.
Queda el coste humano, que casi nadie presupuesta. Con unos 10.000 usuarios activos, prepárese para recibir entre 20 y 60 mensajes de soporte a la semana. Eso es media jornada de una persona, así que pertenece al presupuesto como salario y no como software.
Cuándo se paga, y no solo cuánto
El flujo de caja importa tanto como el total, así que conviene verlo por hitos y no como un pago único. Un proyecto de tamaño medio se reparte en unas 2 semanas de definición, unas 3 de diseño, entre 8 y 12 de desarrollo, unas 3 de pruebas y entre 1 y 2 de envío a las tiendas, de modo que el dinero sale normalmente en cuatro o cinco plazos repartidos a lo largo del proyecto.
El envío a las tiendas tampoco es instantáneo. La revisión de Apple suele resolverse en menos de 48 horas, mientras que Google Play tarda con frecuencia entre 1 y 7 días cuando se trata de una aplicación nueva, y en nuestra experiencia aproximadamente uno de cada tres primeros envíos vuelve rechazado por un detalle de la ficha o de la privacidad. Por eso planificamos una ventana de lanzamiento de dos semanas y no un día de lanzamiento con invitados.
Guarde entre un 10 y un 15 por ciento del presupuesto como reserva para imprevistos, porque un cambio pedido después de aprobar el diseño cuesta habitualmente entre dos y tres veces lo que habría costado ese mismo cambio durante el diseño. Esa es también la razón por la que la palanca más poderosa sobre el coste total está en las tres primeras semanas, cuando cambiar de opinión todavía es gratis y solo hace falta borrar un dibujo.
Cuándo la opción más barata es la correcta, y se lo diremos
No todo el mundo necesita una aplicación, y decirlo forma parte de nuestro trabajo. Una web bien hecha para el móvil o una aplicación web cuesta con frecuencia entre un 30 y un 50 por ciento de lo que cuesta un desarrollo nativo, sale a la calle en semanas, no pasa por revisión de tienda, no paga cuota anual y, sobre todo, demuestra si alguien quiere realmente lo que usted quiere ofrecer.
Si aun así la app tiene sentido, hay dos formas de rebajar el riesgo antes de comprometer todo el dinero: publicar primero en una sola plataforma, o hacer un piloto con 200 usuarios reales por unos pocos miles y escuchar qué dicen cuando la usan de verdad y no cuando se la enseñan en una reunión.
Y una prueba directa, sin adornos: si su aplicación es un formulario, una lista y un acceso con contraseña, sus clientes no se la van a instalar, así que eso debería ser una página de su web y no un icono en un teléfono. En Linkysoft hemos recomendado a más de un cliente gastar menos de lo que venía dispuesto a gastar, porque una app que nadie abre cuesta exactamente lo mismo de mantener que una que factura, y la factura de mantenimiento llega igual.
Cómo leer un presupuesto para no llevarse un susto en el mes siete
Antes de firmar con cualquier proveedor, haga estas cinco preguntas y pida las respuestas por escrito:
- Qué queda explícitamente fuera de este precio.
- Quién es el propietario del código fuente y de las cuentas de las tiendas.
- Cuál es la tarifa por hora para los cambios que pida después del lanzamiento.
- Qué ocurre, y quién lo paga, cuando una actualización del sistema operativo rompe la aplicación.
- Quién custodia la clave de firma y cómo se la entregarían si mañana cambiase de equipo.
Sobre la forma de contratar, el precio cerrado no es un seguro gratuito: la reserva para imprevistos está dentro del número que usted ya ha pagado, así que el precio cerrado tiene sentido cuando el alcance está definido al detalle, mientras que el trabajo por tiempo y materiales encaja mejor cuando el producto todavía se está descubriendo y va a cambiar por el camino.
Exija también que el primer año de mantenimiento venga presupuestado en el mismo documento que el desarrollo, porque si esa línea falta usted está firmando sin conocer el total real, que es precisamente lo que este artículo intenta evitar.
Por último, pregunte qué datos guarda la aplicación, en qué país viven y quién puede leerlos. Una revisión de seguridad antes de publicar cuesta una fracción de lo que cuesta una fuga de datos con clientes de por medio, y si el asunto le preocupa merece la pena leer sobre protección de datos antes de decidir dónde se aloja la información.
Un total a cinco años, calculado de principio a fin
Pongamos un caso concreto y realista: una app multiplataforma de 30 pantallas para una empresa de servicios, desarrollada por unos 45.000 USD, con un coste de funcionamiento de alrededor de 13.000 USD al año. En cinco años eso suma unos 110.000 USD, de modo que el desarrollo representa solo un 41 por ciento de lo que el propietario acaba gastando. Todo lo demás llega después de la celebración del lanzamiento.
Convierta ahora esa cifra en una decisión que puede tomar hoy en su mesa: 110.000 USD repartidos en cinco años son unos 1.830 USD al mes. La aplicación tiene que ganar o ahorrar más que eso, en pedidos, en horas de personal o en clientes que se quedan, para merecer la pena. Si al hacer la cuenta no llega, la respuesta honesta es no construirla, o construir algo más pequeño primero.
La misma aritmética funciona en la banda pequeña, que es donde está mucha gente que lee esto: una app de 12.000 USD con unos 4.000 USD anuales de funcionamiento suma unos 32.000 USD en cinco años, algo más de 530 USD al mes, un listón mucho más fácil de superar para una tienda con clientela fiel o una clínica que se juega las citas perdidas.
Si quiere ver estos números aplicados a su caso, en Linkysoft ponemos precio a su alcance línea a línea, incluidos el mantenimiento del primer año y los servicios que se pagan por uso, sin prisa y sin compromiso: puede escribirnos con lo que tenga en mente, aunque sea un folio a mano, y también echar un vistazo a nuestros proyectos anteriores para ver qué tamaño de app resolvió cada problema.
