Documentación de una app móvil: lista para entregar el proyecto

La prueba de propiedad que entiende cualquier responsable

El propietario debería poder responder a cinco preguntas sin llamar al antiguo proveedor:

1. ¿Dónde está el código exacto de la versión publicada?
2. ¿Quién controla las cuentas de las tiendas, el servidor y la facturación?
3. ¿Cómo se recuperan los datos si algo falla?
4. ¿Qué problemas siguen abiertos y quién los atiende?
5. ¿Puede un equipo nuevo preparar una versión de prueba?

Si alguna respuesta depende de "pregúntale a la persona que lo hizo", la entrega todavía no está cerrada. La documentación útil reduce esa dependencia; no intenta describir cada línea de código.

Las cuentas deben inventariarse desde el primer mes

Conviene crear un registro de servicios mientras se desarrolla la app. Para cada uno, anote para qué se usa, qué empresa es la titular, quién administra el acceso, cómo se recupera la cuenta, cuándo se renueva y dónde aparece el cargo.

El registro suele incluir las cuentas de Apple y Google, alojamiento, base de datos, almacenamiento, dominio, correo transaccional, SMS, mapas, pagos, analítica, avisos de errores y atención al cliente. No todas las apps utilizan lo mismo, pero todos los servicios esenciales deben tener un responsable identificable.

Las cuentas críticas deberían pertenecer normalmente a la empresa que encarga el producto. El estudio entra como usuario con los permisos necesarios. Una única contraseña personal compartida parece cómoda al principio, pero deja un historial pobre y complica la salida de una persona.

Antes de contratar, las preguntas para un estudio de desarrollo deberían incluir la titularidad de cuentas, código, diseños y datos. Es mucho más fácil acordarlo antes de publicar.

El código tiene que coincidir con la app que usan los clientes

Pida los repositorios de la aplicación móvil, el servidor, el panel de administración y cualquier configuración necesaria para desplegar. Un archivo comprimido puede servir como copia adicional, pero no reemplaza un repositorio con historial, etiquetas de versión y cambios trazables.

El documento de puesta en marcha debe indicar las versiones de las herramientas, cómo instalar dependencias, qué variables necesita cada entorno, cómo ejecutar pruebas y cómo crear una compilación. Los secretos no deben aparecer escritos dentro del repositorio; tienen que guardarse en un sistema seguro bajo control de la empresa.

Haga una prueba con una persona que no haya participado en el proyecto. Debe descargar el código, seguir las instrucciones y obtener una versión de prueba. La lista de entrega de código de Koder propone este tipo de verificación porque detecta instrucciones incompletas y dependencias que solo existían en el ordenador de un desarrollador.

Anote también qué versión del servidor corresponde a cada versión publicada en las tiendas. Si nadie puede relacionarlas, una futura corrección puede introducir cambios incompatibles.

El diseño editable evita pagar dos veces

Las imágenes exportadas no bastan. La empresa debe recibir el archivo editable de Figma o la herramienta utilizada, con componentes, estados, estilos, iconos, tipografías y licencias. También debe quedar claro qué recursos son propios y cuáles dependen de una licencia de terceros.

No hace falta guardar todas las conversaciones. Sí conviene explicar las decisiones que afectan al negocio: cuándo se reserva una plaza, cómo se calcula un reembolso, por qué un repartidor no puede revertir cierto estado o qué ocurre al borrar una cuenta.

Entregue además una lista limpia de incidencias. Separe errores confirmados, mejoras futuras y limitaciones aceptadas. Incluya prioridad, impacto, solución temporal y versión afectada. Presentar una aplicación como si no tuviera ninguna deuda pendiente solo traslada la sorpresa al siguiente equipo.

Datos, servidores y copias necesitan una prueba real

Un esquema sencillo debe mostrar la aplicación, el servidor, la base de datos, el almacenamiento de archivos, las integraciones y el panel de administración. El objetivo es que un responsable entienda dónde vive la información y qué servicio se cae si otro deja de responder.

Documente las migraciones de la base de datos, las reglas de conservación, la exportación y las copias de seguridad. Después restaure una copia en un entorno de prueba. Ver la palabra "activo" en un panel no confirma que los datos sean completos ni que el procedimiento funcione.

Incluya las alertas. ¿Quién recibe un aviso si aumentan los errores, fallan los pagos o el servidor deja de responder? Cambie esos destinatarios al terminar la colaboración y compruebe que siguen llegando.

Cuando se recibe un producto antiguo, esta revisión se puede combinar con un análisis de modernización y un plan de mantenimiento. A menudo la entrega descubre dependencias antiguas que conviene estabilizar antes de añadir funciones.

Las tiendas no se transfieren con una contraseña

Las instrucciones de publicación deben explicar el número de versión, la configuración de compilación, las firmas, los canales de prueba, las credenciales para revisión y la forma de volver a una versión estable.

Apple dispone de un proceso formal para transferir una app. Google también explica qué datos se transfieren y qué conexiones deben configurarse de nuevo. En Google Play, por ejemplo, ciertos informes, grupos de prueba y permisos de servicios relacionados no pasan automáticamente.

Pida una demostración de publicación en un canal interno. La persona que recibe el proyecto debe observarla y luego repetirla. Un vídeo corto puede ayudar, pero las instrucciones escritas siguen siendo necesarias porque las interfaces cambian.

Una entrega en tres momentos

No espere al último día. Organice el proceso en tres momentos.

Durante el desarrollo: cuentas a nombre de la empresa, acceso al repositorio y al diseño, decisiones importantes registradas y versiones identificables.

Antes de aceptar: compilación limpia, revisión de permisos, restauración de una copia, lista de incidencias y publicación de prueba.

Después de aceptar: periodo concreto para preguntas, garantía definida, responsables de soporte y revocación de accesos que ya no hacen falta.

La lista abierta de Futurice trata la entrega como un proyecto con tareas y responsables. Ese enfoque evita la falsa idea de que todo se resuelve enviando enlaces en una reunión final.

Señales para detener la aceptación

No cierre el proyecto si la app solo compila en un portátil concreto, la tienda pertenece a una cuenta personal inaccesible, las claves están mezcladas con el código, no se ha probado ninguna copia o el diseño editable no coincide con el producto publicado.

También desconfíe de documentos largos que nunca indican nombres exactos. "Está en la nube" no sirve. Debe aparecer el proveedor, el proyecto, el administrador, el titular de la facturación y el método de recuperación.

La titularidad del código y las licencias depende del contrato y del país. Si existe una duda relevante, un profesional jurídico debe revisar esa parte. La lista técnica ayuda a descubrir qué falta, pero no decide derechos legales.

Cómo lo plantea Appfyl

En un proyecto nuevo empezamos por un mapa de propiedad: código, diseño, tiendas, datos, infraestructura, servicios externos y soporte. Así se pueden crear las cuentas correctas antes de que una solución temporal se convierta en permanente.

Al acercarse la publicación, relacionamos la versión aceptada con su código, sus diseños, su entorno y sus incidencias conocidas. Si recibimos una aplicación existente, primero comprobamos qué se puede abrir, compilar y administrar de verdad.

Para ordenar el alcance inicial, el brief interactivo de Appfyl permite indicar roles e integraciones. Esos mismos elementos deberán tener después un propietario y una guía de operación.

¿Quieres ver cómo Appfyl convierte el alcance en productos lanzados? Ver casos de Appfyl.

Preguntas frecuentes