Una empresa de servicios profesionales nos pidió ayuda con la modernización de su plataforma interna. Habían pedido presupuesto a tres agencias y los números no se parecían en nada: 18.000 €, 45.000 € y 92.000 €. Entre la propuesta más barata y la más cara había un factor cinco. Las tres agencias eran serias y con clientes referenciables. El problema no estaba en ellas.
Estaba en el documento que les habían pasado: tres páginas con bullets generales, capturas del CRM actual y la frase "queremos modernizarlo y que se conecte con la facturación". La agencia de 18.000 asumió que los datos se migrarían a mano y que no había integración con SAP. La de 92.000 incluyó migración asistida con cinco años de histórico, formación al equipo y dos meses de soporte tras la puesta en marcha. Ninguna mentía: cada una rellenó los huecos del pliego según su experiencia previa y su tolerancia al riesgo. Estaban cotizando proyectos diferentes con el mismo nombre.
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 |
Cómo se nota que el pliego está flojo antes de abrir las ofertas
No hace falta esperar a recibir las propuestas para saber que van a divergir. Hay tres síntomas que aparecen siempre.
El primero es que las agencias preguntan mucho durante la fase de cotización. Las preguntas serias son buena señal, porque significa que no quieren cotizar a ciegas. Pero cuando son veinte y elementales (¿en qué tecnología está el sistema actual?, ¿cuántos usuarios?, ¿queréis app móvil?), lo que falta es documentación básica.
El segundo son los presupuestos con términos como "fase de descubrimiento", "estimación a refinar tras kick-off" o "rangos sujetos a definición de alcance". Eso significa que la agencia no tiene suficiente para comprometerse y se reserva el derecho a recotizar. Es un presupuesto orientativo disfrazado de compromiso.
El tercero es la propia dispersión entre propuestas. Si el rango entre la más barata y la más cara supera el factor 2, no estás comparando ofertas: estás comparando interpretaciones. Lo sensato es parar, mejorar el pliego y hacer una segunda ronda antes de decidir.
Lo que debería estar cerrado antes de pedir oferta
Un pliego cotizable no es el que lo define todo al detalle, sino el que reduce a casi cero las decisiones que la agencia tiene que tomar por su cuenta para poner un número. La regla práctica es que dos personas leyendo el mismo párrafo entiendan lo mismo.
Cuando la agencia lee "el sistema debe importar el catálogo desde el ERP", debería saber inmediatamente qué ERP, qué versión, por qué vía (API, archivo plano, acceso a base de datos), con qué frecuencia, qué campos, qué pasa con los productos descatalogados y qué hacer si llega un dato corrupto. Si eso está escrito, dos agencias distintas cotizarán dentro de un margen razonable. Si no, cada una se inventará una respuesta sensata y los números se separarán.
Estos son los bloques mínimos que deberían estar resueltos antes de mandar el pliego:
Contexto y alcance. Qué problema concreto se quiere resolver, qué procesos del negocio están implicados y qué áreas quedan dentro y fuera. La agencia necesita entender el negocio para cotizar el software.
Sistemas y datos actuales. Qué tecnología hay hoy, en qué versiones, qué datos existen (volumen, calidad, dónde viven), qué se migra y qué se deja atrás. Si no lo sabes, lo primero no es el pliego: es una auditoría interna.
Integraciones esperadas. Todos los sistemas con los que la solución va a hablar, en qué dirección, con qué frecuencia y qué pasa si la integración falla. Aquí aparece la mayor parte de los sobrecostes.
Usuarios y carga. Cuántas personas usan el sistema, en qué picos, con qué dispositivos y en qué horario. La diferencia entre "20 usuarios de oficina" y "200 usuarios incluido equipo de campo en móvil" cambia la arquitectura entera.
Requisitos no funcionales. Tiempos de respuesta esperados, ventanas de mantenimiento aceptables, exigencias de seguridad, cumplimiento legal y política de copias y recuperación. Lo que no se menciona, no se cotiza.
Criterios de éxito y entregables. Qué considera la empresa que es "terminado": cuántos entornos, qué documentación, qué formación, qué soporte tras la puesta en marcha. Si el criterio es ambiguo, la agencia tendrá argumentos para cerrar el proyecto antes de que esté listo de verdad.
Restricciones. Plazos no negociables, presupuesto máximo si lo hay, tecnologías obligatorias o vetadas y proveedores existentes con los que hay que convivir. Sirve para que nadie proponga algo inviable.
Los tres primeros bloques y los criterios de aceptación salen casi solos si antes se ha escrito una especificación funcional decente, que es el documento donde se cierran el modelo de datos, los flujos y las reglas que luego el pliego resume.
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.
Qué pasó con el proyecto del principio
La empresa de servicios profesionales con las ofertas de 18.000, 45.000 y 92.000 € paró el proceso. Dedicó un mes a redactar bien el pliego, con apoyo externo, y volvió a pedir ofertas a las mismas agencias. Las nuevas propuestas entraron en un rango de 38.000 a 52.000 €: la dispersión bajó del factor 5 al factor 1,4.
El proyecto se firmó con la agencia que la primera vez había cotizado 92.000 € y esta vez cotizó 41.000. La diferencia no era margen comercial: era ambigüedad. Estaba cobrando por el riesgo de no saber a qué se enfrentaba.
Un pliego bien hecho no es burocracia. Es lo que permite comparar ofertas comparables y contratar con criterio. Cuando un proyecto se desvía en presupuesto, casi siempre se puede rastrear hasta una pregunta que nunca se respondió por escrito. Si te toca escribir uno y no tienes perfil técnico dentro, en asesoría técnica hacemos exactamente ese trabajo antes de que salgas a pedir ofertas.