Presupuestos de desarrollo web y apps: la guía definitiva para agencias y freelancers

Desarrollas webs y apps que funcionan. Tus clientes están contentos con el resultado. Pero antes de empezar el proyecto, vives el mismo suplicio de siempre: ¿cuánto cobro por esto?

El presupuesto de desarrollo web es uno de los documentos más difíciles de elaborar en el mundo de los servicios digitales. El alcance es difuso, el cliente no sabe exactamente qué quiere, los tiempos se alargan y siempre aparece “una cosa más” al final. Si no tienes un sistema claro, cada proyecto se convierte en una caja de sorpresas — normalmente desagradables.

Esta guía es para agencias de desarrollo web, freelancers y estudios digitales que quieren cotizar mejor: más rápido, con más claridad y con más probabilidad de cerrar el proyecto a buen precio.

El problema fundamental del presupuesto en desarrollo web

A diferencia de vender un producto físico, presupuestar un proyecto de desarrollo web implica vender algo que todavía no existe. El cliente tiene una idea — a veces vaga — y tú tienes que estimar cuánto tiempo y recursos se necesitan para hacerla realidad sin haber hecho el análisis técnico completo.

Este desajuste produce tres problemas habituales:

• Scope creep: el proyecto original crece sin parar porque el cliente va añadiendo funcionalidades que “no son para tanto”
• Presupuestos demasiado bajos: para ganar el proyecto calculas ajustado y luego trabajas con pérdidas
• Discrepancias de expectativas: el cliente esperaba una cosa y tú entregaste otra (ambas válidas, pero distintas)

La solución no está en ser más caro o más barato. Está en presupuestar mejor.

Los cuatro modelos de precio en desarrollo web

Antes de elaborar ningún presupuesto, debes decidir qué modelo de precio vas a aplicar. No todos los proyectos son iguales, y el modelo que elijas va a condicionar cómo calculas el precio y cómo lo presentas.

Precio fijo (fixed price)

El cliente paga una cantidad fija por un alcance definido. Es el modelo que más clientes piden porque les da certeza sobre el coste total. También es el más arriesgado para el desarrollador si el alcance no está perfectamente definido.

Cuándo usarlo: proyectos con requisitos muy claros y cerrados. Una web corporativa de cinco páginas con diseño predefinido. Una landing page. Un módulo específico de funcionalidad concreta.

El error más común: aceptar precio fijo cuando el alcance es ambiguo. Si el cliente dice “quiero un portal de clientes con cosas personalizadas”, eso no es un alcance. Es una idea. No cotices precio fijo hasta que no tengas los requisitos concretos.

Por hora (time & materials)

El cliente paga por las horas reales trabajadas a una tarifa acordada. El riesgo se comparte: si el proyecto crece, crece el coste de forma proporcional.

Cuándo usarlo: proyectos de mantenimiento y evolución de sistemas existentes. Proyectos con requisitos cambiantes. Fases iniciales de exploración técnica.

El problema: muchos clientes tienen miedo al modelo por horas porque sienten que pierden el control del coste. La solución: establece un presupuesto estimado máximo y haz seguimiento transparente. “Trabajamos por horas con un techo de 20.000 EUR. Si vemos que nos acercamos, te avisamos antes de seguir.”

Retainer mensual

El cliente paga una cuota fija mensual por un banco de horas reservadas. Ideal para clientes que necesitan evolución continua de su producto digital.

Cuándo usarlo: clientes con producto digital en producción que necesitan mejoras constantes, soporte técnico y nuevas funcionalidades de forma recurrente.

Ventaja: ingresos recurrentes y predecibles para tu agencia o como freelancer. Una de las métricas más sanas que puedes tener en un negocio de servicios digitales.

Por sprint o fase

El proyecto se divide en fases o sprints de dos a cuatro semanas, cada uno con un entregable concreto y un precio cerrado. Al final de cada sprint el cliente decide si continúa.

Cuándo usarlo: proyectos medianos o grandes donde el cliente quiere visibilidad y control. Es el modelo más equilibrado para proyectos complejos.

Ventaja: reduces tu riesgo porque cobras por fases, el cliente ve avances reales y el proyecto puede ajustarse según los aprendizajes de cada iteración.

Cómo calcular el precio de un proyecto web

Tanto si usas precio fijo como por sprint, necesitas estimar el esfuerzo con la mayor precisión posible. Este es el proceso que funciona.

Paso 1: descompón el proyecto en tareas

No cotices el proyecto como un todo. Descompónlo en módulos funcionales y tareas concretas. Para una web corporativa con blog y formulario de contacto, la lista podría ser:

• Análisis de requisitos y wireframing — 4 horas
• Diseño UI en Figma: home + páginas interiores — 12 horas
• Maquetación y desarrollo frontend: home — 6 horas
• Maquetación: páginas interiores (×4) — 8 horas
• Integración del blog con CMS — 8 horas
• Formulario de contacto con notificación por email — 3 horas
• SEO on-page básico: robots.txt, sitemap, metas — 3 horas
• Deploy y configuración del hosting — 2 horas
• Formación al cliente — 2 horas
• Revisiones y QA — 4 horas

Total estimado: 52 horas. Con una tarifa de 60 EUR/hora, el precio base sería 3.120 EUR.

Paso 2: aplica un factor de contingencia

Los proyectos siempre duran más de lo estimado. Las reuniones imprevistas, los cambios de última hora, los bugs inesperados, la formación extra que no estaba en el plan. El factor de contingencia cubre todo eso.

• Proyectos bien definidos: añade un 15–20% sobre tu estimación base
• Proyectos con requisitos menos claros: añade un 25–35%
• Proyectos con tecnología nueva para ti: añade hasta un 40–50%

En el ejemplo anterior: 52h × 1,20 = 62,4 horas → 3.744 EUR. Es más honesto que quedarte corto y luego tener que pedir más dinero o trabajar a pérdidas.

Paso 3: añade los costes externos

Los presupuestos de desarrollo frecuentemente olvidan los costes que no son horas de trabajo:

• Licencias de plugins, temas o librerías comerciales
• Herramientas de diseño (Figma, Adobe CC)
• Servicios de terceros: Stripe, SendGrid, APIs de pago
• Hosting y dominio del primer año
• Imágenes y recursos gráficos de stock

Estos costes deben aparecer desglosados en tu presupuesto, no mezclados con tus horas. El cliente tiene que entender qué está pagando a quién.

Paso 4: considera el coste de adquisición del cliente

¿Cuántas reuniones has tenido para llegar a este presupuesto? ¿Has elaborado una propuesta técnica previa? ¿Has viajado para una reunión presencial? Ese tiempo también tiene valor. Si invertiste seis horas en el proceso de venta de un proyecto de 3.000 EUR, tu margen real ya no es el que calculaste.

Algunos freelancers y agencias cobran una fase de “análisis y propuesta” remunerada antes de presentar el presupuesto definitivo. Si el proyecto es complejo — por encima de 15.000 EUR —, esto tiene todo el sentido del mundo.

Qué debe incluir un presupuesto de desarrollo web

Un buen presupuesto no es solo un número. Es un documento que gestiona expectativas, establece el marco de la relación y protege a ambas partes.

1. Descripción del proyecto y contexto

Demuestra que has escuchado y entendido lo que el cliente necesita. No copies y pegues lo que te dijeron: sintetízalo con tus propias palabras e incluye el objetivo de negocio detrás del proyecto.

“El objetivo de este proyecto es sustituir el proceso manual de registro de clientes por una plataforma web que automatice la captación y el envío de documentación, reduciendo el tiempo de onboarding de tres días a menos de dos horas.”

Eso demuestra que no eres un ejecutor de tareas. Eres un socio estratégico.

2. Alcance detallado: qué incluye y qué no

Lista todos los entregables concretos: pantallas, módulos, funcionalidades, integraciones. Y añade una sección explícita de “fuera de alcance”.

Esta sección es tu mejor defensa contra el scope creep. Si aparece una petición nueva, puedes señalar el contrato: “Eso no estaba en el alcance original. Podemos añadirlo con un presupuesto adicional de cambio.”

3. Tecnología y stack

Indica el lenguaje, framework y herramientas principales que usarás. Esto no es solo para el cliente técnico: le da seguridad de que has pensado en la solución, no solo en el precio.

4. Fases y calendario

Divide el proyecto en fases con fechas aproximadas. Si el proyecto tiene dependencias del cliente — que te proporcione textos, imágenes o accesos —, inclúyelas explícitamente en el calendario. Si el cliente se retrasa, el plazo se mueve.

5. Precio desglosado

Presenta el precio por fase o por módulo funcional, no como un bloque único. Esto tiene varias ventajas: el cliente entiende de dónde viene el precio y lo percibe como más justo; si necesita ajustar el presupuesto, puede negociar quitando módulos en lugar de presionarte para bajar la tarifa global; y en proyectos grandes, facilita las aprobaciones internas.

6. Condiciones de pago

Para proyectos de desarrollo web, el estándar del sector es:

• 30–50% al inicio del proyecto (anticipo)
• 30–40% en un hito intermedio (entrega del diseño o primera versión funcional)
• 20–30% a la entrega final

No empieces ningún proyecto sin un anticipo. No importa lo grande que sea el cliente ni lo convincente que parezca la relación. El anticipo es la prueba de que el proyecto es real.

7. Propiedad intelectual

Especifica cuándo se transfiere la propiedad del código al cliente. Lo habitual: al recibir el pago final. Mientras haya facturas pendientes, el código sigue siendo tuyo.

8. Mantenimiento y soporte post-entrega

Indica qué pasa después de la entrega: ¿hay un período de garantía? ¿Qué cubre (bugs del código entregado, sí; nuevas funcionalidades, no)? ¿Ofreces un plan de mantenimiento mensual? Si es así, inclúyelo como opción en el presupuesto. El mantenimiento es una de las líneas de ingresos más rentables y predecibles para cualquier agencia o freelancer.

9. Número de revisiones incluidas

Define cuántas rondas de revisión están incluidas en el precio y qué pasa si el cliente solicita más. Sin esta cláusula, un proyecto puede convertirse en un bucle infinito de “una cosa más.”

10. Validez del presupuesto

Indica durante cuánto tiempo es válida la oferta. Treinta días es estándar. Después, los precios pueden variar.

El scope creep: cómo prevenirlo desde el presupuesto

El scope creep — el crecimiento no planificado del alcance — es la causa número uno de rentabilidad negativa en proyectos de desarrollo web. Y empieza antes de escribir una línea de código: empieza en el presupuesto.

Estas son las cláusulas que debes incluir siempre:

• Change order explícito: cualquier funcionalidad no incluida en el alcance original requiere una orden de cambio por escrito con precio acordado antes de ejecutarse
• Definición de bug vs. nueva funcionalidad: un bug es algo que no funciona según lo acordado; un cambio en cómo funciona algo ya implementado es una nueva funcionalidad y se factura aparte
• Límite de reuniones incluidas: en proyectos de precio fijo, define cuántas horas de reunión están incluidas; las reuniones cuestan dinero y deben estar en el precio

No tienes que ser inflexible. Tienes que ser claro. Un cliente que entiende las reglas del juego desde el principio las respeta. Un cliente al que nunca le dijiste las reglas seguirá pidiendo “cosas pequeñas” indefinidamente.

Cómo presentar el presupuesto para ganar más proyectos

Presenta siempre tres opciones

En lugar de una sola propuesta, presenta tres versiones del proyecto:

• Opción básica: las funcionalidades esenciales para que el proyecto cumpla su objetivo mínimo
• Opción estándar: la que realmente recomiendas (normalmente la intermedia)
• Opción premium: todo lo anterior más funcionalidades adicionales o mayor nivel de acabado

Esto tiene dos efectos: el cliente pasa de decidir si contratar a decidir cuál contratar. Y la opción intermedia — la que más te interesa vender — se percibe como la más razonable por efecto del anclaje psicológico.

Añade el ROI cuando sea posible

Un presupuesto de 15.000 EUR puede parecer caro hasta que el cliente entiende que el sistema que vas a crear le ahorrará 3.000 EUR al mes en trabajo manual. En cinco meses está amortizado. Pon las cifras encima de la mesa cuando las tengas.

Envía un PDF profesional, no un email con precios

La forma en que presentas tu propuesta comunica tu nivel de profesionalidad antes de que el cliente haya leído una sola línea. Un PDF bien diseñado con tu identidad de marca, estructura clara y lenguaje cuidado transmite confianza. Un email con “el precio sería unos 8.000 euros, más o menos” hace exactamente lo contrario.

Herramientas como DealForge te permiten generar propuestas en formato PDF con tu branding, estructura de precio por fases y condiciones legales, listas para enviar directamente al cliente desde la plataforma — con seguimiento del estado incluido para saber cuándo la han abierto y cuándo hacer el seguimiento comercial.

Errores habituales al cotizar proyectos de desarrollo web

Cotizar sin requisitos claros

Si el cliente no sabe exactamente qué quiere, tú no puedes saber cuánto va a costar. En ese caso, la solución es cobrar por la fase de análisis antes de dar el presupuesto definitivo. Muchas agencias ofrecen un “sprint de discovery” de una semana con precio fijo que incluye entrevistas, wireframes y especificación técnica. Al final de ese sprint, el presupuesto es mucho más preciso y el cliente entiende mejor el alcance.

No cobrar el tiempo de gestión

Las reuniones, los emails de aclaración, la gestión de cambios, la coordinación con proveedores externos... todo eso es trabajo facturable. Si no lo incluyes en el precio, lo estás regalando. Un proyecto que tiene reuniones semanales durante tres meses tiene más de veinte horas de gestión que alguien tiene que pagar.

Bajar el precio para ganar el proyecto

Reducir tu tarifa para competir con propuestas más baratas es una trampa. Atraes al cliente más sensible al precio del mercado, trabajas con menor margen y tienes menos presupuesto para hacer un buen trabajo. La competencia de precio en servicios de desarrollo es una carrera hacia el fondo que nadie gana. Mejor perder ese proyecto y dedicar ese tiempo a clientes que valoren lo que ofreces.

No definir hitos de pago

Si cobras todo al final, tu flujo de caja sufre y aumentas el riesgo de que el cliente regatee la última factura o desaparezca. Los hitos de pago distribuyen el riesgo a lo largo del proyecto.

Olvidar las licencias y herramientas externas

Un plugin de 200 EUR puede parecer irrelevante en un proyecto grande, pero si tienes cinco proyectos así al mes, son 1.000 EUR que salen de tu bolsillo. Cada coste externo debe estar en el presupuesto, con su importe real o estimado.

Estructura de un presupuesto de desarrollo web

Para que no partas de cero en cada propuesta, esta es la estructura que deberías usar como base:

1. Portada: tu logo, nombre del proyecto, fecha, datos del cliente
2. Resumen ejecutivo: objetivo del proyecto y enfoque propuesto en dos o tres párrafos
3. Solución propuesta: descripción técnica, stack tecnológico, decisiones de arquitectura
4. Alcance del proyecto: módulos y funcionalidades incluidas, desglosadas
5. Fuera de alcance: lo que explícitamente no incluye el presupuesto
6. Plan de trabajo y calendario: fases, hitos y plazos de entrega
7. Inversión: precio desglosado por fase o módulo, IVA, condiciones de pago y anticipo
8. Mantenimiento y soporte: qué pasa después de la entrega y opciones de contrato de mantenimiento
9. Sobre nosotros: breve descripción de tu agencia o perfil, proyectos relevantes, tecnologías dominadas
10. Próximos pasos: qué hacer para arrancar (firma, anticipo, reunión de kick-off)

Con DealForge puedes guardar esta estructura como plantilla y reutilizarla en cada propuesta nueva, personalizando únicamente el contenido específico de cada cliente. Lo que antes te llevaba tres horas lo tienes en treinta minutos, con resultado más profesional.

Cómo hacer seguimiento sin resultar pesado

Enviaste el presupuesto. El cliente dijo “lo miro y te digo.” Han pasado cuatro días. ¿Qué haces?

Una secuencia de seguimiento razonable para propuestas de desarrollo web:

• Día 1–2 tras el envío: email breve para confirmar recepción y preguntar si tienen dudas
• Día 5–7: seguimiento con valor añadido: un insight relevante para el proyecto, una pregunta sobre sus prioridades, algo que demuestre que sigues pensando en su caso
• Día 12–15: último contacto antes de que expire la propuesta; recuerda la fecha de vencimiento de forma natural, sin presionar

Si pasados quince días no hay respuesta, el cliente no está listo o ya ha elegido a otro. Cierra el ciclo y sigue. No hay peor inversión de tiempo que perseguir a alguien que no quiere comprar.

Conclusión: presupuesta como un socio, no como un proveedor

La diferencia entre un presupuesto que gana el proyecto y uno que no suele estar en los detalles: en cómo entiendes el problema del cliente, en cómo defines el alcance, en cómo proteges tu tiempo y en cómo presentas el valor de lo que ofreces.

Un buen presupuesto de desarrollo web no es solo un documento de precio. Es la primera entrega real del proyecto: demuestra tu capacidad de análisis, tu orden mental y tu profesionalidad. Si el presupuesto ya impresiona, el proyecto tiene muy buen comienzo.

Trabaja tu plantilla, define tus tarifas con claridad, aplica siempre el factor de contingencia y sé explícito con el alcance. Esas cuatro cosas solas mejorarán tu tasa de cierre y tu rentabilidad más que cualquier bajada de precio.

¿Quieres crear propuestas de desarrollo web en formato profesional, con tu branding y enviadas directamente al cliente? Prueba DealForge y deja de perder horas en documentos de Word para dedicarlas a lo que realmente importa: construir proyectos que funcionen.