Saltar al contenido principal
Arquitectura & Desarrollo
16 de febrero de 2026
3 min de lectura

Cómo estimar correctamente un proyecto web

Por qué los presupuestos cerrados son una trampa

"¿Cuánto cuesta una web?" Sin más contexto, esta pregunta no tiene respuesta útil. Depende de tantas variables que cualquier número sin análisis previo es una invención.

Por qué las estimaciones fallan

1. Incertidumbre inherente

Al inicio de un proyecto, no sabemos lo que no sabemos. Requisitos que parecen simples esconden complejidad. Integraciones "sencillas" tienen documentación desactualizada o APIs que han cambiado.

2. Presión por dar números bajos

Si el cliente compara tres presupuestos y elige el más bajo, los desarrolladores aprenden a subestimar para ganar proyectos. Luego vienen los "imprevistos".

3. Confundir esfuerzo con valor

Una funcionalidad puede llevar 2 horas y aportar enorme valor. Otra puede llevar 2 semanas y no servir para nada. Estimar solo horas no captura esto.

Cómo estimo yo

Rangos, no números exactos

En lugar de "esto cuesta 5.000€", digo "esto está entre 4.000€ y 7.000€, dependiendo de X, Y, Z".

El rango comunica la incertidumbre de forma honesta. Si alguien te da un número cerrado sin haber analizado el proyecto en detalle, probablemente ese número va a cambiar.

Fases con puntos de decisión

  • 1Fase de descubrimiento: definir bien qué se va a hacer
  • 2MVP (Minimum Viable Product): versión mínima funcional — lo justo para validar la idea con usuarios reales
  • 3Iteraciones: mejoras basadas en feedback real

  • Cada fase se presupuesta por separado. Después de cada una, decidimos si seguir, ajustar o parar. Esto protege al cliente de comprometerse con un presupuesto enorme sin saber si la dirección es correcta.

    Supuestos explícitos

    "Este presupuesto asume que:

  • Los textos los proporciona el cliente
  • La pasarela de pago tiene documentación actualizada
  • No hay cambios de alcance durante desarrollo"

  • Si los supuestos cambian, el presupuesto cambia. Dejarlo por escrito evita sorpresas para ambas partes.

    Señales de alerta

    El desarrollador acepta cualquier precio

    Si dice que sí a todo, probablemente no ha entendido el proyecto o piensa cobrar los extras después.

    Presupuesto muy detallado para proyecto indefinido

    Si te dan un desglose de 50 líneas para un proyecto que se definió en una reunión de una hora, algo no cuadra. Ese nivel de detalle requiere más análisis.

    Sin margen para imprevistos

    Todo proyecto tiene imprevistos. Si el presupuesto no los contempla, o los pagas tú después o los paga el desarrollador en calidad.

    Lo que necesito antes de presupuestar

  • Objetivos de negocio, no lista de funcionalidades
  • Ejemplos de webs que te gustan (y por qué)
  • Restricciones reales (tiempo, presupuesto, tecnología existente)
  • Quién toma decisiones y cómo

  • Con esto puedo dar un rango realista. Sin esto, cualquier número es inventado.

    Conclusión

    Una buena estimación comunica incertidumbre, establece expectativas claras y permite tomar decisiones informadas. Un número cerrado sin contexto es una apuesta, no un presupuesto.


    Si estás en fase de definición, puede interesarte también por qué fracasan los proyectos web ↗ antes de pedir presupuesto.

    Etiquetas

    #estimación#presupuesto#gestión

    ¿Te ha resultado útil?

    Explora más artículos en el tablón

    Volver al tablón