Qué entregables esperar en el desarrollo de una app a medida (y cómo evaluar cada fase)

Encargar una app a medida sin saber qué debes recibir en cada fase es como reformar un piso sin pedir presupuesto desglosado: te fías, pagas y solo al final descubres si te han entregado lo acordado. El problema no es únicamente el dinero. Muchos empresarios acaban con una app que funciona, pero sin acceso al código, sin las cuentas a su nombre y dependiendo de por vida del proveedor que la construyó. Esta guía repasa, fase por fase, los entregables concretos que debes exigir y, sobre todo, cómo evaluar si cada uno tiene la calidad que has pagado. La idea es sencilla: al terminar el proyecto, la app tiene que ser tuya de verdad, no un préstamo con condiciones.

Fase de descubrimiento: poner por escrito lo que vas a construir

Antes de escribir una sola línea de código, el equipo debe entender qué quieres y para quién. Esta fase de descubrimiento (o discovery) es la que evita el clásico "yo pensaba que esto estaba incluido" tres meses después. Los entregables que debes recibir son concretos:

Documento de requisitos funcionales: qué hace la app, con qué pantallas, qué roles de usuario existen (por ejemplo, cliente, administrador y repartidor en una app de reparto) y qué puede hacer cada uno.
Historias de usuario: descripciones breves del tipo "como cliente, quiero guardar mi método de pago para no introducirlo cada vez". Son la traducción de tu negocio a algo que el equipo puede estimar y probar.
Documento de alcance: qué entra en el presupuesto y, más importante, qué no. Aquí es donde se aclara si la pasarela de pago, las notificaciones push o el panel de estadísticas están dentro o serán un extra.

Cómo evaluarlo: léelo tú, no un técnico. Si no entiendes lo que va a hacer tu propia app leyendo el documento, está mal escrito. Un buen entregable de descubrimiento se lee sin diccionario y no deja funciones importantes en el aire con frases como "gestión de usuarios" sin detallar qué significa gestionar.

Diseño UX/UI: ver la app antes de que exista

Aquí se decide cómo se usa y cómo se ve la app. No deberías esperar a la versión final para opinar sobre pantallas. Los entregables clave son tres.

Wireframes

Son bocetos en blanco y negro de cada pantalla, centrados en la estructura: dónde va el botón de comprar, cómo se navega del carrito al pago. No llevan colores ni imágenes a propósito, para que discutas la lógica sin distraerte con la estética.

Prototipo navegable

Es el entregable más revelador. Un prototipo (habitualmente en Figma) te permite pulsar por las pantallas en el móvil como si la app existiera, aunque por dentro no haya nada programado. Si tu proveedor no te da un prototipo que puedas tocar antes de empezar a desarrollar, estás aprobando algo a ciegas.

Guía de estilo

Define colores, tipografías, tamaños de botón y espaciados. Su valor real es la coherencia: garantiza que la pantalla de registro y la de perfil se parezcan y que, en el futuro, otro diseñador pueda continuar sin reinventar nada.

Cómo evaluarlo: recorre el prototipo intentando completar las tres acciones más importantes de tu negocio (registrarse, comprar, contactar). Si te pierdes o dudas dónde pulsar, el diseño necesita otra vuelta, y corregirlo en Figma cuesta horas; corregirlo con la app ya programada cuesta semanas.

Arquitectura técnica: los cimientos que no se ven

Esta es la fase que los no técnicos suelen firmar sin mirar, y es un error. La arquitectura condiciona cuánto costará mantener y hacer crecer la app durante años. No necesitas entender cada detalle, pero sí recibir la documentación y hacer las preguntas correctas.

Definición del stack tecnológico: qué lenguajes y frameworks se usarán (por ejemplo, React Native para móvil, Node.js en el servidor). Pregunta si son tecnologías estándar y con comunidad amplia; si te proponen algo exótico, cualquier futuro cambio de proveedor te saldrá caro por falta de programadores disponibles.
Modelo de datos: un esquema de qué información se guarda y cómo se relaciona (usuarios, pedidos, productos). Es la base de que tus datos sean tuyos y exportables el día de mañana.
Documentación de la API: describe cómo se comunican la app y el servidor. Si algún día quieres conectar tu app con tu ERP o con una web, esta documentación es lo que lo hace posible sin depender del equipo original.

Cómo evaluarlo: pide que un tercero técnico independiente revise este documento si tú no puedes. El coste de una segunda opinión es ridículo comparado con descubrir dentro de dos años que la app no escala o que nadie más entiende cómo está montada.

Desarrollo: acceso y visibilidad desde el primer día

Durante la programación, el error más común es quedarte a oscuras hasta la entrega final. Un proveedor serio te da visibilidad continua mediante estos entregables:

Acceso al repositorio de código: normalmente en GitHub, GitLab o Bitbucket. Insiste en que el repositorio esté a tu nombre o al de tu empresa desde el inicio, no en la cuenta personal del proveedor. Esto no es desconfianza, es propiedad: el código que pagas es tuyo.
Builds de prueba: versiones instalables de la app que puedes probar en tu móvil según avanza el desarrollo, por ejemplo con TestFlight en iOS o un APK en Android.
Entorno de staging: una copia de la app que funciona igual que la real pero con datos de prueba, para validar cambios sin tocar la versión que usarán tus clientes.

Cómo evaluarlo: comprueba que recibes builds con regularidad (idealmente cada una o dos semanas) y que puedes entrar al repositorio y ver que hay actividad. Un repositorio con commits frecuentes y descriptivos es señal de trabajo ordenado; uno con tres subidas enormes al final suele esconder prisas.

QA y testing: la prueba de que funciona de verdad

Que la app "vaya" en la demo no significa que esté probada. La fase de control de calidad tiene sus propios entregables documentales:

Plan de pruebas: la lista de escenarios que se van a verificar, desde lo básico (registrarse con un email ya usado) hasta lo crítico (qué pasa si se corta la conexión a mitad de un pago).
Informes de bugs: un registro de errores encontrados, su gravedad y su estado (abierto, corregido, verificado). Herramientas como Jira o incluso una hoja compartida sirven, siempre que puedas consultarlo.

Cómo evaluarlo: revisa que el plan de pruebas cubre los casos límite de tu negocio, no solo el camino feliz. Y exige que, antes del lanzamiento, no queden bugs de gravedad alta abiertos. Un informe con errores marcados como "corregidos" pero sin verificar no vale: pide siempre que la corrección esté comprobada.

Lanzamiento: el momento en el que la app pasa a ser tuya

Esta es la fase donde más gente pierde el control sin darse cuenta. En la emoción de publicar, se firman accesos deprisa y se quedan detalles que después cuesta muchísimo recuperar. Exige estos entregables por escrito:

Publicación en las stores (App Store y Google Play) hecha desde cuentas de desarrollador a tu nombre, no en la cuenta de la agencia. Si la app está publicada bajo la cuenta del proveedor, técnicamente no es tuya y cambiar eso más tarde implica volver a publicar desde cero.
Todas las credenciales: accesos a las stores, al hosting, al dominio, a la base de datos, a los servicios de terceros (pasarela de pago, notificaciones). Entregadas de forma segura y con la propiedad transferida a tu empresa.
El código fuente completo, con la última versión subida al repositorio que ya controlas.

Cómo evaluarlo: haz una prueba sencilla. Entra tú mismo, con tus credenciales, a la cuenta de Google Play y a la de App Store. Si puedes acceder sin pedir permiso a nadie, la propiedad es real. Si tienes que solicitar el acceso al proveedor, aún no eres el dueño.

Post-lanzamiento: garantía y continuidad

El proyecto no termina el día de la publicación. Lo que recibas ahora determina si puedes dormir tranquilo o vivir pendiente del teléfono:

Documentación técnica y de usuario: manuales de cómo está montada la app y cómo se opera el panel de administración.
Periodo de garantía: un plazo (por ejemplo, tres meses) durante el cual los errores que no sean nuevas funciones se corrigen sin coste. Debe estar por escrito en el contrato, no ser una promesa verbal.
Plan de mantenimiento: qué incluye el soporte, con qué tiempos de respuesta y a qué precio, para actualizaciones de iOS y Android, correcciones y pequeñas mejoras.

Cómo evaluarlo: distingue claramente qué entra en garantía (arreglar lo que ya debía funcionar) de qué es mantenimiento de pago (evolucionar la app). Un contrato que mezcla ambos a propósito suele acabar en facturas sorpresa.

La regla de oro: propiedad antes que comodidad

Si tuvieras que quedarte con una sola idea de esta guía, sería esta: en cada fase, pregúntate si lo que recibes te haría libre para cambiar de proveedor mañana. Código en tu repositorio, cuentas a tu nombre, credenciales en tu poder y documentación que otro equipo pueda leer. No se trata de desconfiar del desarrollador, sino de proteger una inversión que puede superar fácilmente los cinco cifras. Un buen proveedor no pone pegas a esto; al contrario, lo entrega proactivamente porque sabe que la tranquilidad del cliente es lo que genera la siguiente recomendación.

Si estás a punto de encargar el desarrollo de una app y quieres asegurarte de recibir cada entregable con la calidad y la propiedad que corresponden, en Tangram Consulting trabajamos con esta transparencia por defecto. Cuéntanos tu proyecto y te explicamos qué recibirías en cada fase antes de que tomes ninguna decisión.