Cómo supervisar a la agencia que te desarrolla el software

Pagas todos los meses, las reuniones van bien, el tono es bueno… y sin embargo no sabrías decir si el proyecto avanza a buen ritmo o te están cobrando el doble de lo que vale. Ese es el problema de tener una agencia de desarrollo sin nadie que la supervise: no es que te engañen, es que no tienes forma de saberlo.

Lo esencial

• Supervisar a un proveedor de software no requiere saber programar. Requiere exigir las cosas correctas y saber interpretar las respuestas.
• Las tres palancas son: acceso (al código y a los entornos), entregas frecuentes (software funcionando, no informes) y propiedad (el código y las cuentas son tuyos, por contrato).
• Si el proyecto ya está en marcha y estás perdido, lo que necesitas es criterio técnico independiente, no cambiar de agencia por impulso.

Por qué se pierde el control (aunque la agencia sea honesta)

La mayoría de proyectos que se tuercen no lo hacen por mala fe. Se tuercen por una asimetría de información: una parte sabe exactamente qué se está construyendo y con qué calidad, y la otra solo ve una demo cada tres semanas y una factura cada mes. En esa asimetría, hasta un proveedor decente acaba tomando decisiones que le convienen a él —usar la tecnología que domina, dejar deuda técnica para ir más rápido, estirar el proyecto— sin que nadie las cuestione.

Y el cliente, mientras tanto, evalúa lo único que puede evaluar: si la demo se ve bonita y si el trato es agradable. Ninguna de las dos cosas te dice si el software aguantará dos años.

Señales de que has perdido el control

• No tienes acceso al código. El repositorio está en las cuentas de la agencia y nadie de tu lado ha entrado nunca. Es la señal número uno.
• Las demos son diapositivas o mockups, no software funcionando en un entorno donde tú puedas entrar a probarlo.
• Todo lo que pides es «complicado», y a la vez todo lo que ellos proponen es rápido. Puede ser cierto; también puede ser una forma de dirigir el proyecto.
• Los plazos se mueven sin explicación causal. Un retraso tiene una razón concreta y verificable; «vamos un poco justos» no es una razón.
• El presupuesto crece por «imprevistos» recurrentes. Un imprevisto es un imprevisto. Cinco imprevistos son un problema de estimación —o de método comercial.
• No sabes qué pasaría si mañana la agencia desaparece. Si la respuesta te da vértigo, ahí tienes el diagnóstico.

Lo que sí puedes exigir sin ser técnico

Acceso, siempre

El código debe estar en un repositorio (GitHub, GitLab) que sea de tu empresa, con la agencia invitada como colaborador —no al revés. Lo mismo con el cloud, el dominio y las herramientas. No necesitas entender el código: necesitas poder dárselo a otro si un día hace falta. Es la diferencia entre contratar un servicio y quedarte atrapado en él.

Entregas frecuentes de software que funciona

Cada dos o tres semanas debe haber algo usable en un entorno de pruebas al que tú entras. No una presentación, no un porcentaje de avance: una URL donde tú, sin ayuda, hagas clic y compruebes que lo prometido está. El porcentaje de avance es la métrica más fácil de inflar que existe; el software funcionando no.

Un canal directo con quien programa

Desconfía de las estructuras donde solo hablas con un gestor de cuenta. No para saltártelo, sino porque las capas de traducción entre tu negocio y quien escribe el código son donde se pierden los requisitos —y donde se esconden los retrasos.

Las tres preguntas incómodas

Sin saber programar, estas tres preguntas te dan más información que una auditoría entera:

1. «¿Qué pasa si mañana os cambio por otro proveedor?» La respuesta correcta es aburrida: os damos el código, la documentación y los accesos, y otro equipo lo coge. Cualquier respuesta que incluya vértigo o dependencia es un hallazgo.
2. «¿Qué cobertura de tests tiene lo que habéis hecho?» No para juzgar el número, sino para ver si existe la práctica. «No tenemos tests» significa que cada cambio futuro es una ruleta.
3. «¿Qué deuda técnica estáis dejando y por qué?» Un buen proveedor tiene una lista y la defiende. Un mal proveedor te dirá que no hay ninguna. Siempre hay.

Qué debe estar en el contrato

Cuándo necesitas supervisión técnica externa

Todo lo anterior lo puedes hacer tú. Pero hay un punto en el que no basta: cuando el proyecto tiene tamaño, cuando las decisiones de arquitectura empiezan a ser caras de revertir, o cuando ya sospechas que algo no cuadra pero no puedes demostrarlo. Ahí necesitas a alguien que hable el idioma de la agencia y se siente de tu lado de la mesa.

Es exactamente el papel de un CTO externo: revisa presupuestos y contratos, entra en las reuniones técnicas, juzga entregas y calidad, y te traduce todo a decisiones de negocio. Tu proveedor sigue ejecutando —no se trata de sustituirlo— y tú recuperas el control. Si lo que quieres es una foto puntual del estado real de lo que te han construido, la vía es una auditoría de software: código, arquitectura, seguridad y deuda técnica, con conclusiones que entiendes sin ser ingeniero.

Y si estás pensando en levantar una ronda, este control deja de ser opcional: todo lo que tu agencia haya dejado sin resolver aparecerá en la due diligence técnica del inversor, y entonces se paga en valoración.

¿Y si la conclusión es que hay que cambiar de agencia?

A veces pasa. Pero cámbiala después del diagnóstico, no antes: si te vas sin entender qué falló, hay muchas probabilidades de repetir el patrón con el siguiente proveedor —normalmente porque el problema no estaba solo en ellos, sino en cómo se definió y se supervisó el trabajo. Y antes de decidir, ten claro cuál es la alternativa: un equipo de desarrollo externo con otro modelo de relación, o montar equipo propio, que resuelve la dependencia pero abre otros frentes.

No necesitas saber programar para controlar a tu proveedor. Necesitas acceso, entregas que puedas comprobar y alguien con criterio de tu lado.