Cómo elegir una agencia de desarrollo de apps móviles

Empieza por comparar el trabajo, no la presentación

Tres propuestas bien diseñadas pueden describir tres aplicaciones distintas. Una incluye servidor, panel de administración y preparación del lanzamiento. Otra supone que ya tienes esos elementos. La tercera promete una fecha, pero no explica qué decisiones debes tomar para cumplirla. Hasta aclarar estas diferencias, comparar el importe final sirve de poco.

Preferimos una primera versión pequeña y bien definida a una promesa de construirlo todo sin criterios de aceptación. Eso no significa que gane siempre la agencia más prudente. El equipo adecuado identifica lo que aún no sabe y propone cómo comprobarlo. Esa capacidad resulta más útil que asentir ante cada función que mencionas.

Entrega la misma explicación a todos los equipos

Describe una persona y algo que necesita terminar. En una escuela online, podría ser un alumno que abre la lección asignada, entrega un ejercicio y recibe comentarios del profesor. “Una plataforma educativa con IA y comunidad” deja mucho más espacio para interpretar el encargo.

Comparte un documento breve con el recorrido principal, los sistemas existentes, los países de lanzamiento, los dispositivos, el estado del diseño y lo que puede esperar. La guía para preparar una estimación ayuda a ordenar esa información. No necesitas una especificación técnica completa para mantener una primera conversación útil.

Pide a cada agencia que explique el proyecto con sus propias palabras. Quizá una piense en cursos grabados, otra en clases en directo y otra en una biblioteca por suscripción. Son productos diferentes. Resolverlo antes de comparar plazos evita discusiones cuando ya se han aprobado pantallas.

Comprueba qué demuestra realmente el portafolio

Abre una app relevante, si está disponible en tu mercado, y prueba su recorrido principal. Después pregunta qué partes desarrolló la agencia, en qué momento participó y si sigue manteniendo el producto. La versión actual de una tienda puede reunir trabajo de varios proveedores.

La experiencia con un problema operativo cercano puede importar más que la coincidencia de sector. Saber gestionar reservas simultáneas, reembolsos y permisos del personal resulta valioso para un negocio de servicios. En cambio, una interfaz atractiva no demuestra por sí sola dominio de una administración compleja.

Solicita una referencia con permiso del cliente o un ejemplo de trabajo anonimizado. Un plan de pruebas, un registro de decisiones o un esquema de entrega permiten conocer el proceso sin exponer información privada. No compartir código confidencial es normal; no poder explicar ningún proceso concreto merece una pregunta adicional.

Usa una tabla de respuestas, no de impresiones

Después de varias reuniones es fácil recordar una conversación agradable y olvidar quién se encargaba del servidor. Anota si cada asunto está claro, pendiente o no es aceptable. Puedes usar puntuaciones, pero una buena media nunca debería ocultar un problema decisivo con la propiedad o la entrega.

A continuación, pide que demuestren una respuesta. ¿Cómo se comprueba una reserva? ¿Cuándo tendrá tu empresa acceso al código? ¿Qué necesitaría otro desarrollador para compilar la app? Una promesa se vuelve mucho más informativa cuando alguien explica cómo se cumple.

Diez preguntas para una reunión que sirva de algo

No hace falta convertir la conversación en un interrogatorio. Usa estas preguntas para profundizar cuando una respuesta deja demasiados supuestos abiertos.

1. ¿Qué podrá completar una persona con la primera versión?
2. ¿Qué función aplazaríais y por qué?
3. ¿Qué dais por disponible de nuestra parte?
4. ¿Quién gestionará reembolsos y excepciones?
5. ¿Qué veremos antes de empezar el desarrollo principal?
6. ¿Cómo demostraréis que el recorrido funciona en los dispositivos previstos?
7. ¿Quién aprueba los cambios y dónde se recoge su efecto?
8. ¿Quién controla el código y las cuentas de producción?
9. ¿Qué ocurre si falta una persona clave del equipo?
10. ¿Qué trabajo se realiza después de publicar?

“Necesitamos comprobar la disponibilidad que devuelve vuestro sistema de reservas” puede ser una respuesta responsable. Lo importante es que venga acompañada de una prueba delimitada y una fecha para decidir. “Las integraciones son fáciles” aporta bastante menos información para elegir.

Un ejemplo para comparar dos propuestas

Imagina una app ficticia para reservar clases. La propuesta A incluye elegir una sesión y pagar. La B añade retención temporal de plazas, cancelaciones, intervención del personal y seguimiento de pagos fallidos. Ambas se llaman “app de reservas”, pero no cubren el mismo servicio.

Pregunta a A si esos comportamientos están incluidos, excluidos o pendientes. Pregunta a B cuáles necesitan automatización desde el principio. Tal vez algunas excepciones poco frecuentes puedan atenderse manualmente, siempre que exista una persona responsable y el usuario reciba una respuesta clara.

Así evitas un error habitual: elegir una propuesta aparentemente más ajustada pensando que toda la operación necesaria estaba implícita. No tienes que exigir la misma arquitectura a las agencias. Sí conviene acordar el mismo resultado de negocio y entender quién se ocupa de cada parte.

Acuerda qué significa terminar una función

Un prototipo navegable demuestra una idea de interacción, no un servicio en producción. Una pantalla de pago que funciona en un teléfono tampoco demuestra recuperación tras un corte de conexión. Distingue aprobación del diseño, aceptación de funciones, preparación del envío y publicación efectiva en las tiendas.

Para una reserva, un criterio podría ser: dos personas intentan comprar la última plaza, solo una recibe confirmación y la otra no queda con un cobro sin resolver. Añade quién proporciona las cuentas de prueba y quién acepta el resultado. La plantilla de especificación permite describirlo con orden.

La guía de GOV.UK sobre historias de usuario relaciona una necesidad con un resultado comprobable. No obliga a adoptar un método de gestión concreto. Para hablar de pruebas reales, consulta también la lista de revisión de calidad.

Mantén el control de las cuentas y de la entrega

Siempre que sea posible, las cuentas críticas deben quedar bajo control de tu empresa, con permisos adecuados para la agencia. Registra quién controla código, tiendas, alojamiento, base de datos, dominio, analítica, archivos de diseño y servicios de pago. El acceso al negocio no debería depender del correo personal de alguien.

Recibir una copia del código no equivale a poder operar el producto. Una entrega utilizable incluye instrucciones de compilación, configuración de entornos, dependencias y publicación de actualizaciones. Las claves se transfieren por un procedimiento seguro, no dentro de un documento público.

Apple documenta su proceso de transferencia de apps y Google tiene requisitos propios. La posibilidad de transferir más adelante no sustituye el acuerdo de titularidad inicial. Consulta las cláusulas legales con un profesional cuando sea necesario: acceso técnico y derechos de propiedad no son idénticos.

Cinco errores que complican incluso una buena relación

El primero es pedir cosas diferentes a cada agencia y tratar las respuestas como ofertas equivalentes. El segundo es aprobar pantallas sin resolver las reglas del negocio. En ambos casos puede haber desacuerdos aunque nadie haya actuado con mala intención.

El tercero consiste en dejar decisiones sin responsable. Si tu equipo no elige proveedor de pagos o política de cancelación, la agencia no puede tomar discretamente esa decisión empresarial. Nombra una persona con capacidad de aprobar y una alternativa cuando no esté disponible.

El cuarto es aceptar promesas ilimitadas sobre IA, herramientas sin código o revisiones. Pueden ayudar, pero hay que preguntar cómo se comprueba el resultado, qué límites existen y cómo se mantendrá. El quinto es posponer el soporte hasta el primer fallo. Aclara antes el canal de incidencias, la urgencia y la diferencia entre corregir un defecto y añadir una función.

Cierra la elección con información que puedas conservar

Antes de firmar, reúne primera versión, exclusiones, dudas abiertas, criterios de aceptación, titulares de cuentas y condiciones de soporte. Un asunto pendiente no obliga a descartar al equipo. Sí exige un responsable y un siguiente paso.

Los proyectos públicos de Appfyl también son una base para preguntar, no una razón para saltarse estas comprobaciones. Plantéanos las mismas preguntas que a otros estudios. Si aún estás definiendo la idea, el breve cuestionario del proyecto organiza una solicitud para revisión; no ofrece una cotización vinculante al instante.

Preguntas frecuentes