Comparar propuestas10 minRevisado 2026-08-27

Qué debe incluir un presupuesto web

Los elementos que permiten entender qué se construirá, quién aporta cada cosa, cómo se valida, qué queda bajo tu control y qué costes continúan después.

Decisión que resuelve: Comparar presupuestos web por alcance, propiedad, validación y coste total.

Un total sin alcance no permite comparar

Dos presupuestos pueden mostrar cifras muy distintas y ser ambos razonables porque no incluyen el mismo trabajo. También pueden parecer similares y esconder diferencias importantes en contenido, propiedad, validación o mantenimiento.

Un presupuesto útil no necesita anticipar cada detalle del proyecto. Sí debe dejar claro qué decisión económica estás tomando y qué ocurrirá si cambia una condición importante.

1. El problema y el resultado esperado

La propuesta debería explicar por qué existe el proyecto. «Diseñar una web moderna» es demasiado abierto. «Permitir que un propietario de negocio entienda tres servicios y reserve una llamada desde móvil» se puede comprobar.

Busca:

  • situación de partida;
  • público prioritario;
  • tarea principal del visitante;
  • objetivo que controla el proyecto;
  • factores externos que no puede garantizar.

Esto evita confundir una entrega correcta con promesas de posiciones, ventas o menciones que dependen del mercado.

2. El alcance visible

No basta con indicar un número de páginas. Conviene saber:

  • qué plantillas o recorridos se diseñan;
  • qué contenido se crea, revisa o migra;
  • qué formularios e integraciones se incluyen;
  • qué idiomas o variantes existen;
  • qué dispositivos y navegadores se comprueban;
  • qué elementos quedan fuera.

Una plantilla de servicio reutilizable no equivale a investigar y redactar diez servicios distintos. El presupuesto debe distinguir estructura, contenido y carga de datos.

3. Responsabilidades

Aclara quién aporta:

  • textos y traducciones;
  • fotografías, logotipos y permisos;
  • accesos a dominio, alojamiento y herramientas;
  • información legal;
  • validación interna;
  • respuesta a cambios durante el proyecto.

Si una dependencia no llega a tiempo, el documento debería explicar su efecto. Una fecha sin responsabilidades es una expectativa, no un plan.

4. Propiedad y acceso

El negocio debería saber qué controla al terminar:

  • dominio;
  • alojamiento;
  • cuentas de analítica y buscadores;
  • repositorio o exportación disponible;
  • licencias;
  • contenidos y archivos fuente acordados;
  • credenciales y procedimiento de salida.

«La web es tuya» no sustituye esta lista. La propiedad práctica consiste en poder acceder, operar y cambiar de proveedor sin perder activos esenciales.

5. Criterios de aceptación

Cada entrega importante necesita una forma de comprobarse. Algunos ejemplos:

  • la navegación principal funciona con teclado;
  • no existe desbordamiento horizontal en tamaños acordados;
  • formularios muestran errores y confirmación;
  • títulos, canonical y sitemap son correctos;
  • redirecciones responden como se definió;
  • el rendimiento se evalúa con condiciones documentadas;
  • las cuentas están bajo el control acordado.

Las WCAG del W3C permiten concretar parte de la accesibilidad. Las métricas web principales aportan una referencia para experiencia técnica. Ninguna etiqueta como «optimizada» reemplaza criterios observables.

6. Cambios y revisiones

«Revisiones ilimitadas» puede ocultar falta de proceso; «dos revisiones» puede ser insuficiente si no se define qué se revisa. Busca:

  • momentos de validación;
  • quién aprueba;
  • cómo se registra una solicitud;
  • qué se considera corrección y qué cambio de alcance;
  • cómo se estima el trabajo nuevo.

Esto protege a ambas partes sin convertir el proyecto en un contrato rígido.

7. Publicación, migración y reversión

Si ya existe una web, el presupuesto debería contemplar inventario de URLs, contenido que se conserva, redirecciones y comprobación posterior. Si es la primera, debe aclarar dominio, DNS, correo y quién tiene autoridad para cambiar cada cosa.

Pregunta cómo se vuelve atrás si la publicación falla. La reversibilidad no implica esperar un desastre; reduce el coste de detectar un problema a tiempo.

8. Coste inicial y coste continuo

Separa:

  • construcción;
  • alojamiento y dominio;
  • licencias;
  • mantenimiento;
  • soporte;
  • contenido futuro;
  • servicios externos;
  • impuestos cuando corresponda.

Una cifra inicial menor puede depender de cuotas o de un proveedor concreto. Una cifra mayor puede incluir trabajo que otro presupuesto deja al cliente. Compara coste total para un periodo razonable y los cambios que previsiblemente necesitarás.

9. Privacidad y datos

Si hay formularios, analítica, reservas o cookies, debe existir una decisión sobre datos, base legal, proveedores y conservación. La guía de cookies de la AEPD es una referencia oficial para España; no conviertas un banner genérico en prueba de cumplimiento.

Una tabla sencilla para comparar

Crea columnas para cada propuesta y filas para:

  • problema y resultado;
  • contenido;
  • recorridos;
  • integraciones;
  • propiedad;
  • aceptación;
  • migración;
  • mantenimiento;
  • exclusiones;
  • coste total.

Marca «incluido», «lo aporta el negocio», «por definir» o «fuera». Las diferencias aparecerán antes de discutir el total.

Si necesitas preparar el alcance desde cero, empieza por qué necesita la primera web de un negocio. Para entender por qué las cifras varían, continúa con qué determina realmente el presupuesto.

Siguiente paso

Compara un alcance escrito, no solo un total.

Primero diagnosticamos la situación. Si podemos ayudar, la propuesta posterior separa alcance, responsabilidades y precio.

Reservar llamada con revisión previa