El día del lanzamiento se trata como la línea de meta, con razón: es el hito visible, lo que se celebra y se reporta. Para una app, es más bien la línea de salida de un compromiso distinto y continuo, porque a diferencia de una web que se mantiene mayormente quieta hasta que alguien la cambia deliberadamente, una app vive dentro de dos sistemas operativos y dos tiendas de aplicaciones que siguen cambiando, quiera el negocio o no.
Las actualizaciones del sistema operativo no son opcionales de seguir
Ambas plataformas móviles principales publican actualizaciones anuales, y cada una puede cambiar cómo se comporta el código existente: un permiso que antes se concedía automáticamente ahora exige una solicitud explícita, una API de la que depende la app queda obsoleta con una cuenta atrás hasta su eliminación, un tamaño de pantalla o un patrón de interacción que la interfaz daba por hecho deja de cumplirse en los dispositivos nuevos. Una app que no se mantiene activamente no tiene por qué romperse el día que sale una nueva versión del sistema operativo, pero acumula pequeñas grietas con cada versión, y para cuando algo se rompe de forma visible, suele deberse a que varios ciclos de actualización de pequeños cambios se acumularon sin atenderse.
Los cambios de política de las tiendas llegan sin aviso y con plazo
Las normas de revisión de las tiendas de aplicaciones cambian según su propio calendario, no el del negocio, y una actualización de política puede exigir un cambio en cómo la app solicita un permiso, presenta una suscripción o gestiona un tipo concreto de datos, con un plazo de cumplimiento adjunto, tras el cual la app puede retirarse por completo de la tienda hasta que se corrija. Esto no es una categoría de riesgo hipotética; es una parte rutinaria de operar en una tienda de aplicaciones, y una app que nadie vigila ante estos cambios se entera de ellos solo cuando ya ha sido retirada o marcada, lo cual es una forma mucho más disruptiva de conocer una actualización de política que leer un registro de cambios de antemano.
La carga de soporte no cesa en el lanzamiento
Cada actualización real de la plataforma subyacente, cada nuevo tamaño de dispositivo, cada caso límite que un usuario real encuentra y que las pruebas no cubrieron, genera una consulta de soporte o un reporte de fallo, y el volumen no disminuye tras el lanzamiento como sugiere el calendario de un proyecto: pasa de "acertar con la primera versión" a "mantener funcionando un producto vivo para personas que ahora dependen de él", que es un tipo de trabajo distinto y continuo, no una versión más pequeña del mismo proyecto finito.
Lo que un plan de mantenimiento debe cubrir realmente
Un plan realista contempla pruebas periódicas frente a las nuevas versiones del sistema operativo antes de que se vuelvan obligatorias, no después de que algo se rompa; un proceso permanente para seguir los cambios de política de las tiendas en vez de descubrirlos mediante un aviso de rechazo; y un canal de soporte realmente atendido por personas, no un formulario que acumula en silencio mensajes sin leer. Nada de esto necesita ser grande —normalmente basta una pequeña asignación regular de tiempo—, pero debe existir como un compromiso definido y continuo, no como la suposición de que una app terminada sigue terminada para siempre.
Por qué esto importa antes del lanzamiento, no después
Vale la pena entender el coste realista de mantener viva una app antes de que salga la primera versión, no después de que el primer atasco de soporte o el primer rechazo de la tienda lo vuelvan inevitable: una app presupuestada como un proyecto puntual, sin una partida continua prevista, es una app que o bien se degrada en silencio o bien exige más adelante una corrección más grande y no planificada, y ambas cosas cuestan más de lo que habría costado planificar el mantenimiento.
Esto se suma a las otras preguntas de construir o comprar tratadas en elegir cómo construir software que encaje con el negocio: una app no es una entrega puntual, del mismo modo que un empleado contratado no es una contratación puntual. Nuestro equipo móvil planifica el compromiso de mantenimiento junto con la construcción, no como una idea añadida después de que la app ya esté en marcha.
