El número de páginas describe la cantidad de contenido público, pero no representa por completo la preparación de contenidos, el diseño a medida, el CMS, los datos de formularios, los permisos, los idiomas, las integraciones, las pruebas y la entrega. Dos webs de cinco páginas pueden ser muy diferentes: una coloca textos aprobados en un diseño existente y otra necesita definir contenido, crear un CMS multilingüe y gestionar consultas en administración. Para comparar de forma justa hay que alinear qué se incluye, quién aporta cada elemento y cómo se acepta el resultado.

No compares únicamente el precio total y las páginas. Compara el alcance entregado frente a los mismos requisitos.

El número de páginas puede seguir siendo útil, pero solo es una medida. Si la propuesta no define profundidad de contenido, componentes compartidos, administración, servicios externos y responsabilidades de publicación, totales parecidos pueden corresponder a proyectos totalmente diferentes.

¿Por qué dos webs de cinco páginas pueden requerir trabajos distintos?

Imagina que ambas empresas solicitan Inicio, Nosotros, Servicios, Proyectos y Contacto:

  • El proyecto A aporta textos e imágenes aprobados, usa un diseño establecido, envía un formulario sencillo por correo y funciona en un idioma.
  • El proyecto B necesita entrevistas, sistema visual propio, migración, gestión en tres idiomas, consultas guardadas, permisos, analítica y avisos.

El número público es igual. El proyecto B incluye estrategia de contenido, modelado de datos, administración, operación multilingüe, integraciones y más aceptación. Llamarlos “web responsive de cinco páginas” oculta la diferencia y dificulta gestionar cambios posteriores.

Ocho factores que definen el alcance

1. Preparación del contenido

Una web necesita más que varios párrafos. Posicionamiento, servicios, público, acciones, permisos de casos, calidad de imagen, traducción y avisos legales necesitan responsables. Si el contenido no está preparado, el proyecto puede incluir entrevistas, arquitectura, redacción, edición, selección y migración.

Confirma antes del presupuesto:

  • ¿Quién aporta textos e imágenes?
  • ¿El proveedor maqueta, revisa o escribe a partir de entrevistas?
  • ¿Los casos y las imágenes tienen permiso público?
  • ¿Se migra todo el contenido antiguo o se revisa primero?
  • ¿Quién aprueba los datos y cada idioma?

2. Plantilla, adaptación o diseño propio

Usar una plantilla probada, adaptarla a la marca y diseñar desde el contenido son alcances diferentes. La interfaz a medida suele incluir jerarquía, estados, móvil, errores, datos vacíos, carga e interacción, no solo una imagen de portada en escritorio.

“Diseño a medida” debería indicar:

  • Páginas y componentes compartidos incluidos.
  • Revisión separada de escritorio y móvil.
  • Definición de rondas de cambios.
  • Formularios, menús, diálogos y errores incluidos.
  • Responsable de logotipo, tipografías, colores y fotografía.

3. CMS y administración operativa

Una página de servicio puede ser un archivo fijo o una entrada de CMS con título, secciones, imágenes, SEO, fechas e idiomas. El resultado público puede parecer igual, pero el segundo necesita estructura de datos, permisos, validación, borradores, vista previa y publicación.

También hay que separar CMS de administración operativa. El CMS gestiona artículos y páginas; otro sistema puede gestionar consultas, pedidos, reservas, miembros, asignaciones y notas privadas. Que ambos se llamen “panel” no significa que tengan el mismo alcance.

4. Complejidad de datos y procesos

Un formulario con nombre y correo no equivale a una consulta formal con servicio, presupuesto, adjunto, consentimiento, origen y estado. Un carrito tampoco es solo un botón: depende de productos, opciones, stock, pago, pedido, avisos y excepciones.

Pregunta:

  • ¿Qué registros creará la web?
  • ¿Qué estados puede tener cada registro?
  • ¿Quién puede ver, modificar, eliminar o exportar?
  • ¿Se conserva el registro si falla el correo?
  • ¿Cómo se tratan duplicados, cambios, cancelaciones o devoluciones?
  • ¿Cuándo se elimina información personal y quién lo hace?

5. Idiomas y versiones de mercado

Una web multilingüe no es una sola página con palabras sustituidas. Cada idioma necesita URL estable, contenido revisado, título, descripción, alternativas de imagen, navegación, canonical y hreflang. Si servicios o información legal cambian por mercado, traducir frase por frase puede ser incorrecto.

La propuesta debe separar traducción, revisión, carga y configuración técnica, además de definir si un idioma incompleto permanece privado o utiliza una regla explícita.

6. Servicios externos e integraciones

Pagos, entrega, correo, mensajería, mapas, reservas, CRM, contabilidad, analítica y acceso social dependen de terceros. Cada conexión puede requerir cuentas, permisos, API, entornos de prueba y producción, tratamiento de fallos y cuotas recurrentes.

Aclara:

  • ¿La construcción incluye conexión y pruebas?
  • ¿Quién paga cuotas de plataforma, transacción y mensajes?
  • ¿Quién responde cuando el proveedor cambia una función?
  • ¿Quién crea y posee las cuentas de prueba y producción?
  • ¿Cómo conserva datos y avisa la web durante un fallo?

7. Pruebas, publicación y bases de búsqueda

Que funcione en el ordenador del proveedor no significa que esté lista para producción. Publicar puede incluir dominio, DNS, HTTPS, alojamiento, base de datos, copias, correo, páginas de error, móvil, navegadores, formularios, permisos y rendimiento.

Si se incluyen bases SEO, hay que definir títulos y descripciones, canonical, hreflang, Sitemap, robots, datos estructurados y redirecciones antiguas. El SEO técnico ayuda a descubrir y entender la web, pero no garantiza posiciones.

8. Entrega, formación y mantenimiento

Tras publicar, la empresa debe saber quién controla dominio, alojamiento, código, datos, diseño y acceso superior. También debe saber cómo actualizar, restaurar y escalar incidencias. “Web publicada” no define una entrega completa.

Confirma:

  • ¿Incluye formación y documentación?
  • ¿Cómo se entregan dominio, alojamiento, código y base de datos?
  • ¿Cómo se separan errores de nuevas necesidades?
  • ¿Cuál es el alcance y plazo de garantía?
  • ¿Mantenimiento, cambios externos y contenido son servicios separados?
  • ¿Cómo se transfieren cuentas y datos al terminar la relación?

Tabla para comparar propuestas

Área Pregunta Omisión habitual
Contenido ¿Quién escribe, revisa, traduce y aprueba? “El cliente aporta contenido” sin formato ni plazo
Diseño ¿Plantilla, adaptación o diseño propio? Solo se aprueba la portada, sin móvil ni estados
Parte pública ¿Qué páginas, componentes e interacciones? Páginas con igual nombre y profundidad distinta
CMS ¿Qué campos e idiomas se pueden editar? Suponer que todo lo visible es editable
Datos operativos ¿Cómo se guardan y asignan consultas o pedidos? Solo correo, sin registro ni alternativa ante fallos
Integraciones ¿Qué servicios externos se conectan? No se indican cuotas ni propiedad de cuentas
Pruebas ¿Qué dispositivos, procesos y entorno deben pasar? Sin datos reales, copias ni estados de error
SEO ¿Qué bases técnicas se entregan? Confundir configuración con garantía de posición
Entrega ¿Quién controla cuentas, código y datos? Sin formación, recuperación ni transferencia
Mantenimiento ¿Qué continúa después de publicar? Garantía, cambios y suscripciones poco claros

Cómo comparar dos propuestas de forma justa

Usa una base común de requisitos

Entrega a cada proveedor la misma información de marca, objetivos, funciones esenciales, idiomas, datos, integraciones y plazos. Si cada uno recibe datos distintos, los totales no son comparables.

Marca incluido, aportado por cliente, adicional o excluido

No dependas de nombres de funciones. Revisa contenido, diseño, CMS, formularios, integraciones, pruebas, publicación, formación y mantenimiento. Pide una definición concreta de expresiones como “SEO básico” o “panel de administración”.

Define la aceptación

Cada función importante necesita una condición observable. “Sistema de consultas completo” debería incluir validación, recepción, conservación, aviso, envío duplicado y fallos, no solo un formulario visible.

Separa construcción y costes recurrentes

Alojamiento, dominio, extensiones, correo, pagos, mensajes, derechos de imágenes y mantenimiento pueden continuar. Separa implementación, cuotas externas y soporte para entender el coste total de propiedad.

Compara riesgo y entrega, no solo funciones

Más funciones no implican un proyecto más completo. Propiedad, copias, permisos, documentación y excepciones suelen reducir mejor el riesgo que una lista larga de funciones sin definir.

Elementos que no deberían quedar “para después”

  • Propiedad de dominio y alojamiento.
  • Responsable y fecha de contenidos e imágenes.
  • Migración de datos de producción.
  • Lugar donde encontrar formularios o pedidos fallidos.
  • Cuotas externas y propiedad de cuentas.
  • Reglas para idiomas incompletos.
  • Diferencia entre borrador, vista previa y producción.
  • Cobertura de copias y responsabilidad de restauración.
  • Límite entre garantía, cambio de contenido y desarrollo nuevo.
  • Archivos, datos y accesos entregados al finalizar.

No son detalles menores: determinan si la web puede gestionarse, aceptarse y transferirse.

Cómo reducir costes evitables

Reducir costes no significa eliminar controles de calidad. Significa reducir decisiones repetidas y alcance innecesario:

  1. Nombrar un responsable que consolide decisiones internas.
  2. Aprobar posicionamiento, servicios y objetivos antes del diseño.
  3. Preparar textos, imágenes y permisos publicables.
  4. Separar funciones esenciales de ideas futuras.
  5. Enumerar sistemas actuales e integraciones necesarias.
  6. Entregar comentarios consolidados en el plazo acordado.
  7. Aprobar datos y proceso antes de ajustar cada detalle visual.
  8. Registrar cambios de alcance para no perder añadidos en conversaciones.

Preguntas frecuentes

¿Cobrar por página siempre es poco razonable?

No. Para webs sencillas con contenido y diseños consistentes, puede ser una unidad útil. El problema es usarla como única medida sin definir profundidad, diseño compartido, administración e integraciones.

¿Un presupuesto más alto garantiza mejor trabajo?

No. El precio no demuestra calidad. Revisa comprensión, alcance, experiencia relevante, propiedad, aceptación y proceso de comunicación.

¿Por qué un CMS aumenta el alcance?

Un CMS no son solo campos. Necesita estructura, validación, permisos, borradores, publicación, archivos, errores y salida pública. Más roles, campos e idiomas requieren más planificación y pruebas.

¿Las cuotas de terceros deben estar incluidas?

Deben estar informadas, aunque no tenga que asumirlas el proveedor. Implementación, suscripciones, transacciones y mantenimiento deben separarse, con propiedad de cuenta clara.

¿Por qué una cifra inicial puede ser solo una estimación?

Porque datos, roles, excepciones e integraciones aún no están definidos. Una estimación responsable indica supuestos y rangos o empieza por requisitos. Una promesa fija con información incompleta suele generar añadidos y retrasos.

Conclusión: relaciona el precio con un alcance claro

Un presupuesto útil explica qué recibe la empresa, qué debe aportar, qué queda fuera y cómo se acepta y entrega el resultado. El número de páginas puede permanecer, pero no sustituye las definiciones de contenido, diseño, datos, integraciones, pruebas y entrega.

Cuando todas las propuestas parten de los mismos requisitos, la empresa puede comparar método, calidad, riesgo y gestión a largo plazo en lugar de adivinar por qué cambian los totales.

Continúa con siete datos que conviene preparar antes de planificar una web y la lista de entrega de una web. También puedes revisar nuestros servicios o iniciar un proyecto indicando objetivos, proceso y funciones esenciales para que Stage of Me te ayude a definir un alcance comparable.