Cómo elegir una empresa de desarrollo de apps

Pregunta qué parte del proyecto hizo el proveedor: investigación, UX/UI, identidad, desarrollo, integraciones o mantenimiento. Un buen diseño de interfaz acredita ese trabajo. Para valorar la implementación, pide que expliquen el funcionamiento y las decisiones que asumieron. Distinguir las disciplinas permite reconocer el valor de cada caso sin atribuirle un alcance que no consta.

Pide ejemplos comparables por dificultad, aunque pertenezcan a otro sector. Puede ser más relevante haber resuelto permisos entre usuarios o trabajo sin conexión que mostrar una app de aspecto similar. Si el caso se puede enseñar, revisa un recorrido completo. Cuando existen limitaciones de confidencialidad, el proveedor puede explicar el problema y su papel sin revelar datos del cliente.

Presenta el problema, los usuarios, los dispositivos previstos y los sistemas que ya utilizas. Observa si el proveedor pregunta por el recorrido, la información disponible y las personas que administrarán el producto. Esas cuestiones ayudan a concretar el encargo. Una propuesta que llega sin aclarar las dependencias puede estar basada en hipótesis que después alterarán el trabajo.

Pide que justifiquen la solución propuesta con las condiciones del proyecto. Si recomiendan una tecnología o un formato, deben explicar qué facilita, qué condiciona y quién podrá mantenerlo. No necesitas dominar todas las herramientas para comparar el razonamiento. Puedes preguntar qué harían si aumenta el contenido, falla una integración o cambia el equipo que gestiona el producto.

Aclara quién será el contacto habitual, quién decidirá sobre el producto y quién resolverá las cuestiones de diseño y desarrollo. Pregunta qué tareas hará el equipo propio y cuáles se coordinarán con colaboradores. Necesitas saber cómo se reparte el trabajo y quién responde cuando una decisión afecta a varias partes del sistema.

Acuerda cómo veréis los avances. Una revisión de pantallas, una demostración funcional y una lista de incidencias ofrecen información diferente. Pide una frecuencia de trabajo adecuada a la disponibilidad de tu equipo y un lugar compartido para registrar decisiones. También hay que definir qué ocurre cuando falta una validación, llega contenido tarde o aparece una petición fuera del alcance.

Pide un ejemplo de criterio de aceptación. En una herramienta de peticiones, podría ser que un usuario envíe una solicitud, que la persona responsable la reciba y que el cambio de estado se vea en ambos lugares. El proveedor debe explicar cómo comprobará ese recorrido y qué hará si una parte falla. Una demostración visual deja muchas de esas preguntas abiertas.

Pregunta quién probará dispositivos, permisos, contenido vacío e interrupciones de conexión según las necesidades del producto. Define también tu papel en la aceptación: aportar datos representativos, revisar el lenguaje o completar tareas con usuarios previstos. Las pruebas deben formar parte del trabajo acordado, con tiempo para corregir lo que se detecte en ellas.

Antes de empezar, revisa cómo se organizarán las cuentas, el repositorio, los archivos de diseño y la documentación. Pregunta quién tendrá acceso durante el proyecto y cómo se preparará la entrega. Si otra persona tuviera que continuar el trabajo, debería poder entender cómo se ejecuta, qué dependencias tiene y dónde se gestiona cada parte.

El soporte posterior necesita un acuerdo propio sobre tareas y canales. Aclara cómo se comunicarán incidencias, quién las revisará y cómo se planificarán cambios o actualizaciones. La disponibilidad del producto depende también de cuentas y servicios externos que alguien tendrá que gestionar. Pide que esas responsabilidades queden asignadas antes de dar el lanzamiento por terminado.

Escribe junto a cada criterio la respuesta recibida y la evidencia que la acompaña. Un caso explicado, una muestra de entrega o una demostración ayudan a valorar afirmaciones generales. Si una respuesta sigue abierta, regístrala como pendiente y pide aclararla antes de elegir. Puedes utilizar esta ficha en la conversación:

• ¿Qué caso muestra una dificultad comparable y qué papel tuvisteis?
• ¿Qué preguntas faltan para definir mi proyecto?
• ¿Con quién trabajaré y cómo revisaré los avances?
• ¿Cómo comprobaremos los recorridos antes de publicar?
• ¿Qué accesos, archivos y documentos se entregarán?
• ¿Cómo se organizará el soporte cuando el producto esté en uso?