Cómo presupuestar un proyecto de software sin equivocarte (guía 2026)

Presupuestar un proyecto de software es una de las decisiones con más impacto en su éxito, y una de las que más se hace con menos criterio. La mayoría de presupuestos se cierran con ofertas inconmensurables entre sí, con costes ocultos que aparecen después y con expectativas no alineadas entre cliente y proveedor.

Esta guía recoge los principios y números orientativos que usamos cuando ayudamos a empresas a presupuestar desarrollo en serio.

Por qué la mayoría de presupuestos fallan

Tres causas explican casi todos los presupuestos que terminan mal:

1. Se presupuesta el alcance inicial, no el total. La primera versión nunca es la versión que se queda en producción.
2. Se compara “precio por hora” entre perfiles muy distintos. Un junior por 40 €/h y un senior por 85 €/h no son comparables en horas totales ni en calidad.
3. Se ignora el coste de coordinación. Cuanto mayor el equipo, mayor el porcentaje del tiempo que se va en reuniones, revisiones y dependencias.

Los 7 bloques que todo presupuesto debe incluir

Un presupuesto honesto y completo debería tener estos bloques, aunque sea de forma orientativa:

1. Descubrimiento y definición (discovery)

Entre el 8% y el 15% del total. Entrevistas, prototipos, validación de hipótesis, priorización. Si el presupuesto no incluye esta fase o la trata como “gratis”, suele ser mala señal.

2. Diseño de producto

Entre el 10% y el 20%. UX, UI, flujos, sistemas de diseño. Se puede reducir si ya existe un sistema consolidado.

3. Arquitectura y setup técnico

Entre el 5% y el 10%. Decisiones de stack, infraestructura, CI/CD, seguridad. Pequeño en horas pero determinante en riesgo.

4. Desarrollo

La partida grande. Entre el 50% y el 65% del total. Incluye frontend, backend, integraciones, QA, y siempre debería incluir refactor y testing automatizado, no añadirlos como extra.

5. QA y calidad

Entre el 8% y el 15%. Puede ir integrada con desarrollo en equipos maduros o separada cuando hay QA dedicado.

6. Lanzamiento y operación inicial

Entre el 3% y el 8%. Despliegue, observabilidad, rollback, soporte los primeros días. Muchas ofertas lo omiten y aparece después como “extra”.

7. Contingencia

Entre el 10% y el 20%. No es relleno: es la partida que cubre lo que todavía no se sabe. Un presupuesto sin contingencia es un presupuesto que va a desviarse.

Costes ocultos que hay que preguntar explícitamente

Estas partidas rara vez aparecen en la oferta inicial pero siempre llegan:

• Infraestructura cloud (AWS/GCP/Azure) durante desarrollo y producción.
• Licencias de terceros (APIs, monitorización, auth, pagos).
• Modelos de IA si aplica (coste por token/uso, mes a mes).
• Mantenimiento post-lanzamiento: bugs, seguridad, dependencias.
• Evolución funcional del primer año (el backlog nunca se cierra).
• Soporte y guardias si hay disponibilidad crítica.

Pregunta siempre: ¿qué costes voy a tener el primer año que no están en esta oferta? Una respuesta clara diferencia a un proveedor serio de uno que quiere cerrar la venta.

Rangos orientativos 2026 (España)

Para un producto web/app de complejidad media, equipo externo, Europa:

• MVP validable (2-3 personas, 2-3 meses): 45.000 € – 90.000 €.
• Producto productivo (squad de 4-5, 4-6 meses): 150.000 € – 300.000 €.
• Plataforma con integraciones serias (squad de 5-7, 6-9 meses): 300.000 € – 600.000 €.
• Producto con IA en el core (squad mixto especialistas IA + producto): 200.000 € – 1.000.000 € según alcance.
• Mantenimiento y evolución anual: 20-35% del coste inicial.

Estos rangos varían mucho según seniority del equipo, complejidad del dominio y ubicación del proveedor. Son orientativos, no regla.

Modelos de contratación: ventajas y riesgos

Precio cerrado

Ofrece seguridad aparente, pero requiere un alcance muy definido. Si el alcance cambia —y casi siempre cambia—, cada cambio es negociación. Tiende a fomentar conservadurismo: el proveedor infla horas para protegerse.

Funciona bien para proyectos muy acotados y con especificación detallada.

Time & Materials con tope

Pagas por tiempo real pero con un tope acordado y mecanismos de reporte semanal. Ofrece flexibilidad real al cambio.

Funciona bien para proyectos donde el alcance va a evolucionar y donde confías en el proveedor.

Squad dedicado por mensualidad

Pagas por un equipo dedicado al mes. No compras horas, compras capacidad. El foco se mueve a qué se entrega, no a qué hora se trabaja.

Funciona bien para relaciones de medio y largo plazo con alta iteración.

Equity / Success fee

Parte del pago en forma de equity o tied a resultados. Solo funciona con mucha confianza por ambos lados y claridad sobre métricas.

Funciona bien en productos muy early y en contadas situaciones.

Cómo comparar dos ofertas sin que te engañen los números

Cuando tienes dos ofertas enfrentadas, el precio por hora es casi inútil para compararlas. Estas son las preguntas que sí ayudan:

1. ¿Quién hará exactamente el trabajo? ¿Seniority? No “un equipo”, nombres y niveles.
2. ¿Qué alcance exacto está dentro? ¿Integraciones, QA, despliegue, seguridad, observabilidad?
3. ¿Qué costes no están? Licencias, infra, mantenimiento.
4. ¿Cuál es la cadencia de entrega? Semanal, quincenal, al final.
5. ¿Qué pasa si pido un cambio?
6. ¿Cuánto va a costar el mantenimiento del primer año?

Una oferta más cara que responde concretamente a estas preguntas suele salir más barata total que una oferta más barata con respuestas vagas.

Señales de alerta en un presupuesto

• No incluye fase de descubrimiento.
• Incluye solo “desarrollo” sin QA ni despliegue.
• Precio redondo sospechoso sin desglose.
• Sin contingencia explícita.
• Sin condiciones claras de cambio de alcance.
• Plazo más corto que lo razonable por ese alcance (suele significar que no se ha pensado bien).

Señales de alerta de tu lado como cliente

• No tienes claro qué problema resuelves con el software.
• No tienes un dueño de producto identificado.
• No has definido cómo vas a medir éxito.
• El proyecto depende de una sola persona interna.

Si alguna de estas aplica, el mejor uso de tu presupuesto igual no es contratar desarrollo todavía, sino invertir en discovery.

---

En Everglow damos presupuestos desglosados, sin costes ocultos y con contingencia explícita, y te decimos honestamente cuándo es mejor no construir todavía. Si quieres una segunda opinión sobre tu presupuesto actual, hablemos.