El problema con los presupuestos de software

La mayoría de presupuestos de software son inútiles en el momento en que se firman. No porque los proveedores sean deshonestos, sino porque el alcance no está definido con suficiente precisión para que el número sea real.

Esta guía te explica cómo funciona la estimación de software desde dentro, para que puedas pedir presupuestos que signifiquen algo y detectar las señales de alerta antes de comprometerte.

Cómo se estima el coste de un proyecto

Todo proyecto de software se puede descomponer en tres variables:

Coste = Tiempo × Número de personas × Coste/hora

El problema es que el tiempo es la variable más difícil de estimar, y cualquier error en ella se amplifica con las otras dos.

Por qué los proyectos se retrasan

Los estudios del sector (Chaos Report, McKinsey, Standish Group) coinciden: más del 60% de los proyectos de software se entregan tarde, sobre coste o con menos funcionalidades de las prometidas. Las causas principales:

Alcance mal definido: el cliente pide "algo como Airbnb" y el proveedor estima sin haberlo descompuesto en detalle.
Requisitos que cambian: lo que parecía claro en el papel cambia cuando el cliente lo ve funcionando.
Deuda técnica oculta: si se integra con sistemas existentes, siempre hay sorpresas.
Estimaciones optimistas: los equipos tienden a estimar el mejor escenario, no el más probable.

Las dos modalidades de contratación

Precio cerrado (Fixed Price)

El proveedor se compromete a un precio por un alcance definido. Si el alcance cambia, el precio cambia.

Cuándo funciona bien:

El proyecto está muy bien especificado antes de empezar.
El alcance es estable y no va a cambiar.
El equipo tiene experiencia previa con proyectos similares.

Riesgos:

El proveedor añade colchón de riesgo (10-30% más caro de entrada).
Si el proyecto va bien, el proveedor gana más. Si va mal, el cliente sufre recortes en calidad o funcionalidades.
Los cambios de alcance generan conflictos.

Time & Materials (T&M)

El cliente paga por el tiempo real invertido. El alcance puede evolucionar.

Cuándo funciona bien:

El proyecto es exploratorio o innovador.
Los requisitos van a evolucionar durante el desarrollo.
El cliente quiere involucrarse en el proceso.

Riesgos:

El cliente asume el riesgo de desviación de costes.
Requiere más implicación y seguimiento por parte del cliente.
Necesita confianza mutua y buena comunicación.

La recomendación de Polaris: para proyectos nuevos, preferimos T&M con un presupuesto máximo acordado. Para proyectos bien definidos con alcance estable, precio cerrado con gestión de cambios clara.

Rangos de coste orientativos (mercado español, 2026)

Estos son rangos reales de mercado para equipos con experiencia. Las agencias más baratas existen, pero el coste real (retrasos, retrabajos, soporte post-lanzamiento) suele ser mayor.

| Tipo de proyecto | Rango orientativo | Tiempo típico | |-----------------|-------------------|---------------| | Landing page / web corporativa | 3.000 – 15.000 € | 3–8 semanas | | MVP funcional (web o app) | 15.000 – 60.000 € | 6–16 semanas | | Plataforma SaaS básica | 60.000 – 150.000 € | 4–8 meses | | Integración con sistemas existentes | 10.000 – 50.000 € | 4–12 semanas | | Proyecto de IA / ML | 20.000 – 100.000 € | 2–6 meses | | Plataforma compleja (HL7, ERP, etc.) | 150.000 € + | 6–18 meses |

Los rangos asumen equipos de 2-4 personas con tarifa de mercado (600-1.200 €/día). Equipos offshore pueden ser más baratos, con implicaciones en comunicación y calidad.

Qué incluir en un briefing para pedir presupuesto

Cuanta más información des al proveedor, más precisa será la estimación. Este es el mínimo que deberías preparar:

1. Contexto del negocio

¿Qué problema resuelve el producto?
¿Quién lo va a usar y con qué frecuencia?
¿Hay sistemas existentes con los que debe integrarse?

2. Funcionalidades

Lista de funcionalidades ordenadas por prioridad (must-have / nice-to-have).
Flujos de usuario principales (puede ser un diagrama simple o una descripción en texto).
Ejemplos de productos similares que os gusten como referencia.

3. Restricciones técnicas

¿Hay tecnología obligatoria (cloud específico, lenguaje, base de datos)?
¿Hay normativa aplicable (RGPD, HIPAA, MDR, PCI-DSS)?
¿Hay usuarios concurrentes esperados o volúmenes de datos relevantes?

4. Plazos y presupuesto

¿Hay fecha límite? ¿Por qué?
¿Cuál es el rango de presupuesto disponible? (Ser transparente aquí ahorra tiempo a todos)

Señales de alerta en un presupuesto

🚩 El proveedor da precio sin haber hecho preguntas. Una estimación seria requiere entender el proyecto. Si te dan número antes de entenderte, es un número inventado.

🚩 El precio es significativamente más bajo que el mercado. Alguien asume ese riesgo: o recortarán en calidad, o añadirán costes después.

🚩 No hay desglose de partidas. Un presupuesto opaco es imposible de negociar o de entender si hay desviaciones.

🚩 No se menciona el mantenimiento post-lanzamiento. El software tiene un coste operativo (hosting, soporte, actualizaciones). Si no está en el presupuesto, aparecerá después.

🚩 El contrato no define claramente qué pasa con los cambios de alcance. Los cambios son inevitables. Si no hay un mecanismo acordado, habrá conflictos.

El coste real de un proyecto de software

El presupuesto inicial es solo una parte del coste total. Considera también:

Infraestructura: hosting, bases de datos, CDN, servicios cloud (100 – 3.000 €/mes según escala).
Licencias de terceros: APIs, librerías comerciales, herramientas SaaS integradas.
Mantenimiento: corrección de bugs, actualizaciones de seguridad, compatibilidad con nuevas versiones del SO o browsers.
Evolución: el software que funciona genera peticiones de mejora. Presupuesta un 15-20% del coste inicial anual para evolución.
Tiempo interno: el proyecto requiere dedicación de personas de tu equipo. Ese tiempo tiene coste aunque no aparezca en la factura del proveedor.

Cómo estimar el coste de un proyecto de software: guía para no técnicos