Lo habitual es que cuando alguien pide tres presupuestos al mismo software, el más caro doble al más barato. En un proyecto bien especificado, las propuestas suelen entrar en un margen del 30-40%. Cuando la diferencia es de 5× o 10×, no es que dos agencias sean honestas y una cara: es que están cotizando proyectos distintos con el mismo nombre.
Ese desorden tiene causas concretas. No son misteriosas y se pueden anticipar. Repasamos las cinco más frecuentes con ejemplos reales (anonimizados) de proyectos que hemos auditado.
Causa 1: alcance de migración no definido
Una empresa de distribución pidió tres presupuestos para sustituir su ERP por uno cloud. Una agencia cotizó 22.000 € y otra 78.000 €. Las dos eran correctas para lo que entendieron.
La agencia barata asumió que los datos del ERP antiguo se exportarían a CSV y se importarían "tal cual" en el nuevo. Tres días de trabajo de migración. La cara incluía análisis de calidad de datos, deduplicación de clientes (tenían el mismo cliente repetido entre 1 y 4 veces por errores históricos), conciliación de catálogos de productos (cuatro nomenclaturas distintas conviviendo), reconstrucción del histórico de cinco años con códigos transformados y validación con responsables de cada área. Veintidós días de trabajo.
Cuando preguntamos a la dirección qué quería realmente, la respuesta fue "lo limpio, pero rápido". No existía esa opción. Tenían que elegir entre datos limpios con dos meses extra de proyecto, o salir antes con el caos heredado y limpiar después en producción (lo cual es siempre más caro).
El cliente nunca había puesto por escrito el alcance de la migración. Cada agencia rellenó el hueco según su tolerancia al riesgo.
Causa 2: integraciones con respuesta ante fallo no especificada
Un proyecto de portal cliente para una empresa de servicios profesionales recibió presupuestos de 35.000 €, 58.000 € y 110.000 €. La parte de presentación era similar en las tres. La diferencia estaba en cómo trataban una integración con la herramienta de facturación.
La agencia barata cotizó "sincronización de facturas con la herramienta interna" como una llamada al endpoint de facturación. Si el endpoint estaba caído, la operación fallaba y el usuario veía un error. Cinco días de trabajo.
La cara cotizó la misma integración con cola de mensajería, reintento automático con backoff, dashboard de seguimiento de envíos pendientes, notificación al equipo de operaciones si una factura llevaba más de seis horas sin sincronizar y reconciliación nocturna automática para detectar discrepancias. Treinta y dos días.
El pliego decía "el portal debe sincronizar las facturas con la herramienta de facturación". Las dos agencias estaban cumpliendo el pliego. La cara estaba cumpliendo lo que probablemente quería el cliente, pero no estaba escrito. La barata estaba cumpliendo lo escrito, sabiendo que aparecerían bugs en producción durante el primer año.
Causa 3: requisitos no funcionales asumidos por defecto
Un proyecto de tienda online para una pyme con catálogo de 8.000 referencias recibió tres ofertas de 12.000 €, 28.000 € y 64.000 €. Las funcionalidades cotizadas eran las mismas en las tres. Lo que cambiaba eran los supuestos.
La agencia barata asumió tráfico de hasta 200 usuarios concurrentes en pico, hosting compartido y disponibilidad esperada del 98% (lo que permite caídas de hasta 14 horas al mes). Stack estándar, sin caché especial. Cumpliría el caso típico.
La intermedia asumió 1.000 concurrentes, infraestructura dedicada, disponibilidad del 99.5% (3,6 horas mensuales) y caché en frente. Adecuado para tráfico de campañas regulares.
La cara asumió 5.000 concurrentes en picos de Black Friday, arquitectura multi-zona, disponibilidad del 99.9% (43 minutos mensuales), caché distribuido, plan de contingencia y observabilidad completa. Adecuado para tráfico fuerte y eventos críticos.
El cliente, una pyme con 200 pedidos al día y un día fuerte al año, no necesitaba lo de 64.000 €, pero tampoco quería arriesgarse con lo de 12.000 si esa Black Friday le iba a tirar la web. Sin números en el pliego, las tres agencias se posicionaron donde su cliente medio les había llevado a posicionarse.
Causa 4: criterios de "terminado" no acordados
Un proyecto de CRM a medida acabó costando 38.000 € a una empresa que había firmado por 24.000. Toda la diferencia eran "extras" facturados durante el desarrollo. Lo curioso es que la agencia no estaba inflando: estaba cobrando lo que no estaba en el pliego.
El pliego decía: "el CRM debe permitir registrar oportunidades, asociarlas a contactos y empresas, y reportar el estado del pipeline a final de mes." La agencia construyó eso. Funcionaba. Pero faltaron tres detalles: la importación inicial de los 5.000 contactos del Excel histórico, los permisos diferenciados entre comerciales y dirección (un comercial no debía ver oportunidades de otros), y la integración con el calendario corporativo para que las llamadas registradas creasen citas.
Las tres cosas eran obvias para el cliente. Asumió que estaban incluidas. La agencia las facturó porque no estaban escritas. Discusión legal-comercial larga, malas relaciones, factura final pagada con resignación.
Si los criterios de aceptación hubieran estado escritos ("el CRM se considera entregado cuando los 5.000 contactos del histórico están migrados, los permisos por rol funcionan según matriz adjunta y la integración con Google Calendar está operativa"), no habría habido discusión y el presupuesto inicial habría reflejado la realidad.
Causa 5: stack tecnológico no acotado
Un proyecto de plataforma interna para una empresa industrial recibió ofertas de 45.000 €, 95.000 € y 140.000 €. Las tres tecnológicamente competentes, las tres con propuesta de arquitectura distinta.
La barata propuso un stack monolítico en PHP con MySQL. La intermedia, una solución en Node.js con servicios separados. La cara, microservicios en Java con Kafka, Kubernetes y plan de escalado. Las tres eran "correctas" para el problema descrito, pero implicaban costes muy distintos de mantenimiento, perfiles diferentes para evolucionar el sistema y curvas de aprendizaje para el equipo interno (que no existía aún).
Cuando preguntamos qué tenía sentido para esa empresa (15 usuarios internos, sin previsión de crecer a 200, sin equipo técnico propio, presupuesto limitado para mantener), la respuesta era clara: el stack monolítico sencillo. La empresa podría haber acotado eso en el pliego ("solución autocontenida, sin necesidad de microservicios, mantenible por un freelance senior") y se habría ahorrado interpretar tres propuestas con tres filosofías arquitectónicas distintas.
Resumen comparativo
Cuando el pliego no cubre estos cinco bloques, los presupuestos divergen no por incompetencia sino por interpretación. Esta es la traducción típica de cada hueco a sobrecoste:
| Bloque omitido | Sobrecoste posible | Razón |
|---|---|---|
| Alcance de migración | 30-200% del módulo | Limpieza de datos, conciliación, validación |
| Integraciones sin respuesta ante fallo | 50-500% del módulo | Cola, reintentos, observabilidad |
| Requisitos no funcionales sin números | 50-300% del proyecto | Arquitectura sobredimensionada o infradimensionada |
| Criterios de "terminado" sin matriz | 20-80% extra final | Trabajo no presupuestado facturado a posteriori |
| Stack no acotado | Variable, hasta 3× | Coste de mantenimiento futuro, perfiles |
El cálculo invertido
Hay quien hace la cuenta al revés: si pides un buen pliego, sacrificas tres semanas de tu tiempo escribiéndolo (o pagas a alguien externo entre 3.000 y 8.000 € por que te ayude a hacerlo). El proyecto luego cuesta lo justo y se entrega cuando se debe.
Sin pliego, esas tres semanas se las ahorras al equipo de tu empresa, pero se las pagas multiplicadas a la agencia que escogiste. Por dos vías: la cifra inicial es más alta de lo necesario (el riesgo está incluido) y los extras durante el proyecto son más numerosos (las cosas no escritas se facturan). El sobrecoste medio que vemos en proyectos sin pliego frente a proyectos con uno bien hecho está alrededor del 60-80%, sobre proyectos de 30-50.000 €. Eso son entre 18.000 y 40.000 € de diferencia.
La aritmética rara vez sale a favor de saltarse el pliego.