Checklist antes de contratar desarrolladores de apps

La elección del equipo de desarrollo es la decisión que más impacta en el resultado de tu proyecto. Un equipo equivocado puede costarte el doble del presupuesto, meses de retraso y una app que no funciona como esperabas.

Esta checklist es el resultado de los errores más comunes que cometen las pymes al contratar.

Checklist completa: antes de firmar

Parte 1: Evaluación del portfolio

• ¿Tienen proyectos similares al tuyo en el portfolio? Un portfolio de apps de ecommerce no garantiza que puedan hacer una app de logística con GPS. Buscá proyectos con complejidad similar y mismo tipo de funcionalidades.

• ¿Las apps del portfolio están en producción y funcionando? Buscá las apps en App Store o Google Play y verificá que estén activas, que tengan reseñas reales de usuarios y que la última actualización no sea de hace 2+ años.

• ¿Podés ver o revisar el código de algún proyecto anterior? Muy pocos proveedores van a mostrar el código de un cliente, pero algunos tienen proyectos de código abierto o demos. Si podés ver código, revisá que no sea un desastre.

• ¿El portfolio incluye el tipo de tecnología que vas a usar? Si van a hacer tu app en React Native, buscá proyectos anteriores en React Native, no solo proyectos de apps genéricos.

Parte 2: Referencias de clientes

• ¿Tienen referencias de al menos 2–3 clientes anteriores dispuestos a hablar? Un proveedor con trabajo real tiene referencias que dan referencias. Si dudan o ponen obstáculos, es señal de alerta.

• ¿Podés contactar a los clientes directamente (no a través del proveedor)? La conversación tiene que ser directa, sin el proveedor presente.

• Preguntas que hacerle a los clientes anteriores:

  • ¿El proyecto se entregó en el plazo y presupuesto acordados?
  • ¿Cómo fue la comunicación durante el proyecto?
  • ¿Hubo problemas? ¿Cómo los resolvieron?
  • ¿Contratarían al mismo equipo de nuevo?
  • ¿Hay algo que hubiesen hecho diferente?

Parte 3: El equipo asignado

• ¿Sabés exactamente quiénes van a trabajar en tu proyecto? No el equipo de ventas ni el CEO. Los desarrolladores y diseñadores específicos que van a tocar tu código.

• ¿Cuántos proyectos simultáneos tiene ese equipo? Un desarrollador trabajando en 4 proyectos al mismo tiempo va a ser menos efectivo que uno en 2. Preguntá explícitamente.

• ¿Qué pasa si uno de los miembros del equipo deja la empresa durante el proyecto? ¿Tienen redundancia? ¿Hay proceso de documentación y handover?

• ¿El equipo tiene todos los perfiles necesarios? Para una app mediana necesitás: PM, diseñador UX/UI, desarrollador frontend, desarrollador backend y QA. Si un solo desarrollador va a hacer todo, el resultado va a reflejar eso.

Parte 4: Propiedad y acceso al código

• ¿El repositorio va a ser de tu propiedad desde el primer commit? El repositorio de código (GitHub, GitLab, Bitbucket) tiene que estar en una cuenta que vos controlás. No en la cuenta del proveedor.

• ¿Vas a tener acceso al repositorio durante el desarrollo, no solo al final? Podés ver qué se está construyendo, cuánto progreso hay y qué calidad tiene el código.

• ¿Está explícito en el contrato que el código fuente es tuyo? La propiedad intelectual del código tiene que estar en el contrato, no solo como acuerdo verbal.

• ¿Las cuentas de App Store y Google Play van a estar a tu nombre? Las cuentas de developer (Apple: USD 99/año, Google: USD 25 único) tienen que estar en tu nombre. Si el proveedor las crea en las suyas, quedás atado a él para publicar actualizaciones.

Parte 5: El proceso de trabajo

• ¿Cómo se comunican durante el proyecto? (canal, frecuencia, responsable) Slack, email, reuniones semanales. Lo que importa es que haya un canal principal claro y que las respuestas sean en tiempo razonable.

• ¿Con qué frecuencia dan actualizaciones de avance? Actualizaciones semanales con demos funcionales son el mínimo razonable. "Cuando hay algo para mostrar" no es suficiente.

• ¿Usan alguna metodología de gestión? (Scrum, Kanban, etc.) No necesitás entender los detalles, pero sí saber que hay un proceso y no es caótico.

• ¿Cómo manejan los cambios de alcance? Los cambios son inevitables. El proceso tiene que estar definido: cómo se solicitan, cómo se estiman y cómo se aprueban. Sin proceso, cada cambio es una potencial disputa.

• ¿Hay un PM (project manager) asignado? Para proyectos de más de 3 meses, tener un PM dedicado reduce enormemente los problemas de comunicación y gestión.

Parte 6: El contrato

• ¿El alcance está descrito en detalle? (lista de funcionalidades incluidas y excluidas) "Una app de delivery" no es un alcance. "App con login por email, catálogo de productos, carrito, checkout con MercadoPago, historial de pedidos y panel de administración" sí lo es.

• ¿La estructura de pagos está atada a hitos, no a fechas? Pagos por entregables verificables (entrega del diseño, primer sprint funcional, beta, producción) es mejor que pagos por fechas del calendario.

• ¿Hay cláusula de propiedad intelectual explícita? "El cliente es dueño del código desarrollado para este proyecto" tiene que estar en el contrato.

• ¿Hay garantía post-lanzamiento y por cuánto tiempo? 30–60 días de corrección de bugs sin costo adicional es razonable. El alcance tiene que ser explícito.

• ¿Hay proceso de resolución de conflictos? Mediación o arbitraje antes de recurrir a la justicia. Acelera la resolución de disputas.

Parte 7: Señales de alerta

Antes de firmar, verificá que ninguna de estas señales esté presente:

• ✗ No pueden mostrar referencias de clientes o ponen obstáculos para contactarlos
• ✗ El presupuesto llegó en menos de 24 horas sin preguntas sobre el proyecto
• ✗ No pueden decirte quiénes van a trabajar específicamente en tu proyecto
• ✗ El contrato no menciona propiedad del código ni de las cuentas de tiendas
• ✗ No tienen proceso definido para manejar cambios de alcance
• ✗ El precio es significativamente más bajo que todos los demás presupuestos
• ✗ Se niegan a hacer un proyecto de prueba pequeño antes de comprometerse al proyecto completo

El "mini-proyecto de prueba" antes del proyecto grande

Una práctica muy efectiva antes de contratar un equipo para un proyecto grande: encargales un mini-proyecto de prueba. Puede ser:

• Una pantalla del diseño
• Un módulo pequeño de la app
• Una revisión técnica del código de un proyecto anterior

El costo es bajo (USD 500–2.000) y la información que obtenés es invaluable: calidad del código, velocidad, comunicación, proceso. Si el mini-proyecto sale bien, tenés mucha más confianza para comprometerte al proyecto completo.