Cómo contratar un squad de desarrollo verificado (sin confiar solo en el portfolio)

Contratar un squad de desarrollo verificado significa mirar más allá de lo que el equipo dice de sí mismo. El portfolio, las referencias curadas y las reviews de cinco estrellas son señales autodeclaradas — fáciles de embellecer porque las controla quien las muestra. Las señales verificables son otra cosa: historial de código real, cumplimiento de plazos medido en el tiempo, diversidad de clientes y disputas resueltas con evidencia. Esas no dependen de que alguien las redacte a favor del squad — o existen, o no existen.

¿Por qué no alcanza con mirar el portfolio y las reviews?

El incentivo para embellecer una reputación es real y está medido. Un estudio de Michael Luca (Harvard Business School, 2011) sobre reseñas de Yelp encontró que subir un punto el rating de un negocio puede aumentar sus ingresos entre un 5% y un 9% — el tipo de impacto económico que explica por qué tantos proveedores de servicios, no solo restaurantes, tienen incentivos para inflar su reputación online. La FTC de Estados Unidos terminó prohibiendo formalmente las reviews compradas, las incentivadas y las fabricadas con IA a través de una regla federal en 2024, precisamente porque el problema escaló lo suficiente como para requerir regulación.

Nada de esto significa que el portfolio o las referencias no sirvan — sirven como punto de partida. El problema es tratarlos como prueba suficiente. Un caso de éxito bien presentado no dice si ese squad entrega a tiempo de forma consistente, con cuántos clientes distintos trabajó, ni qué pasó la última vez que algo salió mal.

¿Qué señales sí son difíciles de fabricar?

Hay un puñado de señales que no dependen de la narrativa comercial del squad porque se generan como subproducto de trabajar de verdad:

• Historial de código real en GitHub — commits con autoría y fecha, no una captura de pantalla del proyecto terminado.
• Cumplimiento de plazos medido en el tiempo (on-time rate), no autodeclarado en una llamada de ventas.
• Diversidad de clientes — si el squad entregó con distintas empresas o depende de una sola relación que podría no repetirse.
• Disputas y cómo se resolvieron, con la evidencia del scope y el avance disponible — no solo el resultado final.

¿Qué preguntas hacer antes de firmar?

Más allá de las señales que se pueden auditar de forma independiente, hay preguntas concretas que separan a un squad que sabe explicar cómo trabaja de uno que solo sabe venderse:

• ¿Cómo manejan el proceso — hay sprints, reuniones regulares, testing definido, o directamente “ya lo vas a ver”?
• ¿El código pasa por code review antes de mergear, con pull requests y un segundo par de ojos, o lo escribe una sola persona sin revisión?
• ¿Cuál es la proporción entre gestión y desarrollo? Si hay más gente coordinando que codeando, se está pagando overhead de coordinación, no capacidad técnica.
• ¿La propiedad intelectual del código queda explícitamente en manos de la empresa contratante, por escrito, o el contrato dice algo vago como “según ley local”?
• ¿Qué pasa después de la entrega — hay soporte post-lanzamiento acordado, o el squad entrega el código y desaparece?

¿Qué pasa si el squad no puede responder estas preguntas con precisión?

Una respuesta vaga sobre seguridad, sobre el proceso de testing, o sobre quién es dueño del código, no mejora después de firmar el contrato — empeora, porque ya no hay incentivo para aclararla. La forma en que un squad responde durante la evaluación es, en la práctica, la mejor muestra disponible de cómo va a comunicarse durante el proyecto.

Cómo lo resuelve Zenit — sin depender de una llamada de ventas

En vez de pedirle a la empresa que audite manualmente el historial de cada squad, Zenit construye esa verificación en la infraestructura. Cada milestone se libera a través de SafePay contra criterios de aceptación firmados de antemano, así que el cumplimiento de plazos queda registrado, no autodeclarado.

ZenitRank cruza esas señales — código, milestones, diversidad de clientes, disputas — en un puntaje que se actualiza solo, sin que el squad pueda editarlo.

Y antes de llegar a ese punto, Kaizen —el motor de discovery de Zenit— ya entendió el proyecto en profundidad, así que el match no depende de un pitch de ventas bien armado sino del historial real de cada squad frente a proyectos comparables.

El framework de arriba funciona para evaluar cualquier squad, esté en Zenit o no: separar lo que se dice de lo que se puede verificar. La diferencia es qué tan fácil o difícil te resulta hacer esa verificación — y ahí vale la pena elegir la infraestructura correcta, no solo el proveedor correcto.