Cómo Elegir un Proveedor de Desarrollo de Apps Móviles

Elegir al proveedor de desarrollo de apps móviles correcto es una de las decisiones de mayor impacto que tomará un fundador de startup o un product owner. Contrata una agencia mediocre y pasarás los próximos doce meses apagando incendios de releases con bugs, discutiendo el alcance y eventualmente reescribiendo el codebase de todas formas. Contrata una buena y obtienes un producto listo para producción, una arquitectura clara que puedes entregar a un equipo interno, y un proveedor que identifica problemas antes de que se conviertan en emergencias. Esta guía te da un marco concreto para distinguirlos antes de firmar nada.

Empieza con el Problema, No con el Pitch

La mayoría de los compradores evalúan proveedores mirando el sitio web de la agencia, leyendo algunos casos de estudio y saltando a una llamada de demo. Ese proceso selecciona buenos vendedores, no buenos ingenieros.

Antes de hablar con nadie, escribe un brief de una página que describa el problema que estás resolviendo, los flujos principales que tu app debe soportar, cualquier restricción de plataforma o integración, y un rango aproximado de tiempo y presupuesto. Envía este brief a cada proveedor que evalúes. La calidad de su respuesta te dice más que cualquier cosa que digan en una llamada.

Un buen proveedor volverá con preguntas de aclaración — sobre tus usuarios, tu modelo de datos, tus expectativas de backend y qué significa "terminado" para ti. Un proveedor débil volverá con una propuesta que repite tu brief y le añade un precio.

Cómo Auditar el Portafolio

Los casos de estudio del portafolio son marketing, no evidencia. Lo que importa es lo que hay detrás. Al evaluar el trabajo anterior de cualquier agencia, haz tres cosas:

¿Puedes hablar directamente con el cliente? Cualquier agencia respetable ofrecerá al menos una llamada de referencia con un cliente anterior. Si esquivan, eso ya te dice algo. En la llamada, pregunta específicamente: ¿el proyecto se entregó a tiempo? ¿Qué falló en producción los primeros tres meses? ¿Los contratarías de nuevo?

¿La app en vivo está realmente en vivo? Descárgala. Revisa la calificación y las reseñas en el App Store. Mira la fecha de la última actualización. Un "caso de estudio insignia" que no se ha actualizado en dos años y tiene 2,8 estrellas no es una referencia — es una advertencia.

¿Su stack encaja con tu problema? Si necesitas una app Flutter, busca proveedores que hayan lanzado apps Flutter en producción, no proveedores que "también hacen Flutter" como una de ocho tecnologías. En Codevia, nos concentramos en Flutter, React Native y .NET — no porque no podamos aprender otras herramientas, sino porque la profundidad en pocos stacks supera la familiaridad superficial con muchos.

Señales de Alarma que Deben Detener la Conversación

Estos son patrones que constantemente preceden proyectos fallidos. Cualquiera de ellos merece una pausa seria. Más de uno y deberías alejarte.

• Sin fase de discovery. Si un proveedor envía una propuesta con alcance y precio fijos antes de hacer cualquier pregunta sobre tu dominio, tus usuarios o tus datos — están adivinando.
• Entregables vagos. "Desarrollo de app móvil" no es un entregable. Una app que pasa la revisión del App Store, incluye tests unitarios con al menos 60% de cobertura y usa un enfoque documentado de gestión de estado — eso sí es un entregable.
• Sin rol de QA en el equipo. Las agencias de desarrollo que no incluyen un rol de QA te entregarán bugs y lo llamarán pruebas de aceptación.
• No posees el código hasta el pago completo. Insiste en la propiedad del código desde el primer commit, en un repositorio que tú controles.
• "La arquitectura la definimos sobre la marcha." La arquitectura que emerge orgánicamente de decisiones sprint a sprint es deuda técnica con otro nombre. Un buen proveedor propone una arquitectura antes de escribir una línea de código.

Preguntas para la Llamada de Evaluación

1. Cuéntame cómo manejaron un proyecto que salió mal. Qué fue mal, cómo lo detectaron y qué hicieron. Los proveedores que han lanzado proyectos reales tienen historias reales de fallos.
2. ¿Cuál es tu proceso entre mi aprobación de un diseño y el primer build testeable? Esto revela cómo manejan el handoff, las decisiones de gestión de estado y la definición del contrato de API.
3. ¿Cómo gestionan los cambios de alcance a mitad del proyecto? Buena respuesta: un proceso formal de control de cambios con evaluación de impacto antes de comprometerse. Mala respuesta: "somos flexibles, solo dinos."
4. ¿Cómo es el soporte post-lanzamiento? Los bugs encontrados en producción después del lanzamiento son inevitables. ¿Cuál es su SLA? ¿Está incluido o se factura aparte?
5. ¿Puedo ver una muestra de código o hacer una revisión técnica breve? No todos los proveedores aceptarán, pero los buenos sí. Incluso revisar un repositorio público de GitHub da señales sobre la calidad del código y los hábitos de documentación.

Precio Fijo vs Tiempo y Materiales: Cuándo Usar Cada Uno

Precio fijo funciona cuando el alcance está genuinamente bien definido. Si tienes wireframes, una especificación de API, un documento claro de criterios de aceptación y ya has hecho esto antes — el precio fijo es apropiado. Transfieres el riesgo de alcance al proveedor. El proveedor incluye ese riesgo en el precio, así que pagas una prima, pero tienes predictibilidad de costos.

El precio fijo falla cuando el alcance es exploratorio, cuando esperas aprender de builds tempranos y cambiar de dirección, o cuando construyes un MVP y deliberadamente dejas decisiones de producto abiertas.

Tiempo y Materiales (T&M) funciona cuando quieres flexibilidad. Pagas por el tiempo real empleado, puedes repriorizar libremente, y el proveedor no tiene incentivo para recortar esquinas para proteger márgenes. El riesgo que asumes es la imprevisibilidad de costos.

Para la mayoría de MVPs de startups, T&M con un presupuesto tope y revisiones mensuales de hitos es la estructura correcta.

Lista de Verificación de Due Diligence

Lista de Due Diligence para Proveedor

Portafolio
[ ] Descargado y probado al menos dos apps en vivo que construyeron
[ ] Revisadas calificaciones y reseñas recientes en App Store / Play Store
[ ] Confirmado que las apps están mantenidas (última actualización en 6 meses)
[ ] Completada al menos una llamada de referencia directa con un cliente anterior

Técnico
[ ] Confirmado el equipo que trabajará en tu proyecto (no solo ventas)
[ ] Preguntado sobre enfoque de arquitectura y obtenido una respuesta concreta
[ ] Revisado código público o recibido una muestra
[ ] Confirmado que el rol de QA está incluido
[ ] Preguntado sobre expectativas de cobertura de tests

Comercial
[ ] Confirmado que la propiedad del código es tuya desde el primer commit
[ ] Revisadas las cláusulas de asignación de propiedad intelectual
[ ] Confirmado acceso al repositorio (tú eres el dueño del repo)
[ ] Entendido el proceso de control de cambios para cambios de alcance
[ ] Entendidos los términos y precios del soporte post-lanzamiento

Proceso
[ ] La fase de discovery o scoping está incluida (no solo llamadas de ventas)
[ ] Definido qué significa "terminado" en el contrato
[ ] Cadencia de sprints y calendario de demos acordados por escrito
[ ] Ruta de escalación para disputas documentada

¿Listo para Evaluar Codevia?

Construimos productos móviles en Flutter y React Native para startups y PYMES. Trabajamos de forma transparente — el repositorio es tuyo desde el primer día, documentamos las decisiones de arquitectura a medida que las tomamos, y no aceptamos proyectos donde no podemos ser honestos sobre el alcance.

Si eso suena como el tipo de socio que buscas, empieza con nuestra página de desarrollo de apps móviles o contáctanos directamente. Trae tu brief y volveremos con preguntas reales.