La respuesta corta

El presupuesto de una app se desvía casi siempre por lo mismo: no por lo que se estimó mal, sino por lo que no se estimó.

El desarrollo se presupuesta bien. Lo que falta es todo lo demás — y «todo lo demás» no es un porcentaje de contingencia, es una lista concreta de partidas que se pueden nombrar de antemano.

Esta es esa lista.

1. Antes de construir

  • Discovery o definición de alcance. El coste de no hacerlo aparece después, multiplicado.
  • Diseño y sistema de diseño. No son lo mismo: el sistema de diseño es lo que hace que la pantalla treinta cueste menos que la tercera.
  • Investigación con usuarios, aunque sean cinco entrevistas.
  • Definición de analítica. Qué se va a medir y cómo se llama cada evento. Decidirlo después significa perder los datos de los primeros meses.

2. Cuentas, licencias y accesos

Pequeñas en importe, grandes en calendario si se olvidan:

  • Cuentas de desarrollador de Apple y Google, con su cuota y su verificación — que puede tardar, y el proceso está en la cuenta de empresa de Apple y el D-U-N-S.
  • Certificados y su renovación, con responsable asignado.
  • Servicios de terceros: notificaciones, crash reporting, analítica, mapas, correo transaccional. Casi todos escalan con el uso.
  • Infraestructura: entornos de desarrollo, pruebas y producción, no solo producción.
  • Licencias de contenido: tipografías, iconos, fotografía, música.

3. Calidad

  • Dispositivos físicos de prueba. Gama media y baja, que es donde falla, no el último modelo del equipo.
  • QA manual además de automatización.
  • Auditoría de accesibilidad, obligatoria en sector público y recomendable en el resto.
  • Auditoría de seguridad o pruebas de intrusión, en cualquier producto que mueva dinero o datos sensibles.

4. Publicación

  • Material de tienda: capturas por dispositivo, textos, vídeo. Multiplicado por cada idioma y territorio.
  • Ciclos de revisión, incluido el rechazo. Planificar como si fuera a la primera es planificar mal.
  • Textos legales: privacidad, condiciones, y su revisión jurídica.
  • Traducciones, que no son solo la app: también la ficha de la tienda y los textos legales.

5. Lo que empieza el día del lanzamiento

Aquí es donde se rompen los presupuestos anuales:

  • Mantenimiento correctivo: los fallos que aparecen con usuarios reales.
  • Mantenimiento evolutivo de plataforma, que no añade valor visible y es obligatorio. Cada año hay requisitos nuevos de las tiendas y versiones mínimas que suben — el ejemplo vivo es la exigencia de versión objetivo en Google Play, en auditar el código de una app heredada.
  • Soporte a usuarios, con alguien detrás.
  • Contenido. Si la app enseña catálogo, avisos o noticias, alguien los mantiene. Es la partida que más se olvida y la que decide si la app sigue viva.
  • Analítica y mejora continua, o el producto se queda como salió.
  • Renovación de cuentas y certificados, anual.

6. Lo que casi nadie pone

  • Traspaso. Que otro equipo pueda continuar es un entregable, y cuesta.
  • Documentación mantenida, no escrita una vez.
  • Formación del equipo interno del cliente.
  • Retirada. Qué pasa el día que la app se descontinúa: datos, usuarios, tiendas. Rara vez se piensa y siempre llega.

Cómo presentarlo sin que parezca inflado

Un presupuesto que enumera estas partidas parece más caro que uno que no las tiene. Lo es solo en apariencia: el otro también las tiene, pero aparecen después y sin previsión.

Dos formas de presentarlo que funcionan:

  1. Separar construcción de operación. Un importe de proyecto y un coste anual de tenerla viva. Son dos decisiones distintas y quien firma agradece verlas separadas.
  2. Marcar qué es obligatorio y qué es opcional. Renovar certificados no es opcional. Un rediseño, sí.

Y una recomendación honesta para quien compra: si recibes dos ofertas y una es mucho más barata, compara las listas de partidas antes que los importes. Casi siempre la diferencia no está en el precio hora: está en lo que una incluye y la otra deja para más adelante.

Antes de pedir un presupuesto

  1. ¿Está incluido el mantenimiento de plataforma, y por cuánto tiempo?
  2. ¿Quién mantiene el contenido después del lanzamiento?
  3. ¿Los entornos y los servicios de terceros van a nombre de quién y quién los paga?
  4. ¿El traspaso está en el alcance?
  5. ¿Qué pasa el año dos?

La quinta es la que distingue una app que se lanza de un producto que se sostiene.

Los rangos que publicamos y qué incluye cada tipo de proyecto están en precios, y para simular un caso concreto está la calculadora.