7 señales de que tu agencia de desarrollo va a decepcionarte

Sexta semana de desarrollo y un fundador pide un enlace. La agencia manda una diapositiva: tres barras verdes, una ámbar, una nota que dice integraciones al 80%. Un entorno desplegado no existe. No ha existido desde el kickoff. El proyecto todavía no ha fracasado, pero va a hacerlo.

La distancia entre lo que te cuentan y lo que puedes abrir en el navegador es donde se pierde el dinero de un proyecto de software. Un estudio de McKinsey y la Universidad de Oxford sobre más de 5.400 proyectos IT midió que los grandes se pasan un 45% del presupuesto, un 7% del plazo y entregan un 56% menos de valor del previsto, con el sobrecoste creciendo alrededor de un 15% por cada año extra de duración (McKinsey, 2012). Esos números son el punto final. Las señales aparecen en el primer mes y para leerlas no hace falta saber programar.

Aquí van siete. Cada una tiene una explicación inocente y aburrida, así que una señal sola es ruido. Tres a la vez son un patrón.

1. Quien vendió el proyecto no es quien lo desarrolla

El sénior que en la llamada respondía a cada pregunta de arquitectura lleva tres semanas callado. En los dailies aparecen nombres nuevos. Preguntas por qué se decidió algo en la segunda semana y en la sala no estaba nadie.

Es estructural, no un engaño: la gente que sabe plantear un proyecto escasea y se rota entre propuestas comerciales. La factura la pagas tú igualmente, en velocidad que baja, preguntas que vuelven y decisiones tomadas antes del traspaso que acaban siendo tradición oral.

Pide: los nombres de quien va a tocar el código, su nivel y el preaviso por escrito antes de cualquier cambio de persona. Si no llega respuesta en un correo, ese equipo aún no está montado.

Explicación inocente: una baja, una excedencia, un contrato terminado. Entonces pide el documento de traspaso. Si existe, no es una señal.

2. Llegan estados de avance, nunca cosas que puedas abrir

Porcentajes, semáforos, un burndown. Ninguna URL, ningún historial de commits, ninguna lista de defectos abiertos. "Vamos por el 80%" es una afirmación, no una medida, y se puede repetir igual cuatro semanas seguidas.

Un equipo que al acabar la segunda semana no te enseña software funcionando o no lo está escribiendo o no quiere que lo mires. En los dos casos el problema es tuyo.

Pide: un entorno desplegado cada semana, desde la segunda, en el estado en que esté. Feo e incompleto vale. Ausente no. Con el log de commits y el número de bugs abiertos al lado.

Explicación inocente: las dos primeras semanas fueron de verdad infraestructura, login y pipeline. Entonces en la tercera aparece el enlace.

3. El presupuesto llegó antes que las preguntas

Precio cerrado y plazos en 48 horas después de una sola llamada. Nadie preguntó por los datos que ya tienes, por las obligaciones de cumplimiento, por las integraciones ni por quién aprueba una publicación.

El PMI atribuye a una gestión de requisitos imprecisa el 47% de los proyectos que no alcanzan sus objetivos (PMI, Pulse of the Profession). Los requisitos no desaparecen porque nadie los haya recogido: vuelven más tarde como cambios facturables, justo cuando tienes menos capacidad de negociar.

Pide: la lista escrita de lo que el presupuesto excluye y de las hipótesis en las que se apoya. Quien ha pensado tu proyecto la escribe en una página. Aquí explicamos qué debe entregar de verdad una fase de discovery.

Explicación inocente: el alcance es pequeño y lo han hecho once veces. Entonces la lista de exclusiones será corta y concreta.

4. La velocidad sube y la estabilidad no

Las pull requests se cierran rápido. La lista de bugs crece cada viernes. La misma regresión ha vuelto dos veces.

El informe DORA 2025 sobre desarrollo asistido por IA, con casi 5.000 respuestas, encontró que a mayor adopción de IA corresponde más inestabilidad en las entregas, aunque la productividad individual mejore (DORA, 2025). Hoy el código se genera más rápido de lo que la revisión y el despliegue pueden absorber. En 2026, un proveedor que publica demasiado rápido para mantenerlo correcto falla más a menudo que uno lento.

Pide: tasa de fallo de los despliegues y tiempo de recuperación, no story points. Dos números, cada mes, en un correo.

Explicación inocente: una semana de migración dura. Entonces la curva de defectos se aplana al sprint siguiente y alguien te lo había avisado antes.

5. Del alcance te enteras por la factura

Que el alcance se mueva es normal. Los datos del PMI sitúan el scope creep en torno al 41% de los proyectos en un año (PMI). La señal no es el cambio: es dónde te enteras.

Si la primera vez que se pone precio a un cambio es en una factura, un proceso de control de cambios no existe, y el incentivo juega en tu contra: cada ambigüedad del brief se convierte en ingreso.

Pide: un proceso de cambios por escrito, acordado antes de necesitarlo, con tarifas y un umbral de aprobación por debajo del cual las cosas pequeñas simplemente se hacen. Sobre dónde va esa cláusula escribimos la diferencia entre SOW y MSA.

Explicación inocente: una urgencia en producción que no podía esperar una firma. Entonces pasó una vez y te llamaron.

6. Nadie dice nunca que no

Cada petición recibe un sí. Nadie nombra una contrapartida, nadie discute el orden de las cosas, nadie te ha dicho que una función va a costar más de lo que devuelve.

Un proveedor sin opiniones o no está pensando en tu producto o cuenta con facturarte las consecuencias de no haberlo pensado. La frase más útil que puede decirte una agencia es "esto no lo haríamos todavía, y te explico por qué".

Ponlos a prueba: pide algo caro y un poco absurdo. Una app móvil nativa en el segundo mes. Una pipeline de analítica a medida antes de tener usuarios. Mira si alguien frena, y en cuánto tiempo.

Explicación inocente: lo que has pedido hasta ahora era sensato y estaba bien ordenado. La prueba se resuelve en un día.

7. No puedes ver el repositorio

El código vive en su organización. Los accesos ya llegan. El contrato enumera entregables pero no dice de quién es el código fuente, y una cláusula de depósito no aparece.

Esta señal funciona distinto de las otras seis. No predice la decepción: decide cuánto te va a costar. Todos los demás problemas de la lista se recuperan si tienes el código y las credenciales de despliegue. Ninguno se recupera si no los tienes.

Pide: el repositorio en tu organización desde el primer commit, con la agencia invitada como colaboradora, y las cuentas cloud a tu nombre. Quien ponga pegas debe saber explicar por qué en una frase. Las fórmulas contractuales están en ocho cláusulas a revisar.

Explicación inocente: un repo plantilla compartido los primeros días, migrado en el kickoff. Pide la fecha.

Qué hacer cuando llevas tres contadas

La jugada cara es reempezar en silencio: esperar que el siguiente sprint lo arregle mientras corre el reloj. La duración es la variable que multiplica el coste, y cada mes de espera empeora el desvío en lugar de reducirlo.

1. Escribe lo que has observado, con fechas y sin adjetivos. "Semanas 3, 5 y 7: pedida una URL desplegada, recibida una diapositiva de estado." Los hechos viajan; el enfado no.
2. Manda el documento y pide respuesta por escrito en cinco días laborables. Cómo responden ya es el siguiente dato.
3. Acuerda dos semanas de corrección con un único resultado demostrable. Un entorno que funcione. Las personas acordadas de vuelta en la llamada. Un registro de cambios. Algo que puedas abrir, no algo que puedan contarte.
4. Si la ventana se cierra vacía, usa la cláusula de salida. Llévate repositorio, credenciales, documentación y backlog. Y haz una revisión del traspaso antes de contratar al siguiente.

Cómo evitar las siete antes de firmar

Cuatro puntos en los papeles quitan casi todo el riesgo, y ninguno es una petición rara.

• Personas clave nombradas en la SOW, con un preaviso por escrito antes de sacar a nadie de tu cuenta.
• Un entorno desplegado como hito de pago dentro de las dos primeras semanas. Esa cláusula sola elimina la señal 2 y buena parte de la 4.
• Repositorio y cuentas cloud en tu organización desde el primer commit.
• Un proceso de control de cambios por escrito y con tarifas, acordado antes de que exista la primera petición.

Si todavía estás en la fase de brief, casi todo sale más barato arreglado antes: aquí van cómo redactar el brief para una agencia de desarrollo y los errores más comunes al elegir estudio.

Nosotros estamos al otro lado de la mesa, y ese es justamente el punto: son las preguntas que esperamos de quien compra, y las mismas que haríamos si estuviéramos comprando. Ninguna exige saber leer código. Exigen que cualquier afirmación sobre el avance venga pegada a algo que puedas abrir.