Cuánto cuesta hacer una página web: qué determina el presupuesto

El coste de una página web cambia según el trabajo que deba resolver. Una web corporativa con contenido preparado tiene un alcance diferente al de una web orientada a captar solicitudes, una tienda online o una plataforma conectada con otros sistemas.

Por eso, un precio solo resulta útil cuando indica qué incluye. Para comparar presupuestos necesitas conocer el objetivo, las páginas, los contenidos, las funciones, las integraciones, las pruebas y los costes que continuarán después del lanzamiento.

No existe un rango económico universal que permita comparar proyectos con alcances distintos. Esta guía no publica una cifra de mercado sin contexto: explica cómo identificar qué proyecto necesitas, preparar su alcance y detectar si dos presupuestos están valorando el mismo trabajo.

Respuesta rápida: de qué depende el precio

El tipo de proyecto es el punto de partida, no el presupuesto completo.

Dos proyectos de la misma categoría pueden requerir trabajos distintos. Una tienda con pocos productos y operativa sencilla no equivale a un catálogo con variantes, varios almacenes, reglas de envío y facturación integrada.

Antes de presupuestar: separar objetivo, alcance y solución

Una petición mejora cuando distingue tres capas:

“Queremos una web a medida” describe una preferencia de solución. “Queremos que una empresa entienda tres servicios y pueda solicitar una valoración aportando la información necesaria” describe un objetivo. A partir de ahí se decide el alcance y, después, la solución técnica adecuada.

Esta separación evita presupuestar funciones que no apoyan el objetivo y permite comparar alternativas sin dar por elegida una tecnología desde el principio.

Qué determina cuánto cuesta hacer una página web

Objetivo y recorrido del usuario

Una web informativa puede limitarse a explicar servicios y ofrecer contacto. Si debe generar solicitudes, reservas o ventas, hay que definir qué información necesita el visitante, qué acción completará y qué recibirá la empresa.

El presupuesto debería indicar los recorridos principales, no limitarse al número de páginas.

Contenido

Textos, fotografías, fichas, documentos y vídeos necesitan responsables. El alcance cambia si la empresa entrega el contenido aprobado o si hay que ordenarlo, redactarlo, adaptarlo, cargarlo o migrarlo.

También importa la variedad. Una página de servicio, una ficha de producto y un recurso editorial pueden necesitar estructuras y revisiones diferentes.

Diseño y componentes

Configurar una estructura existente no requiere las mismas decisiones que crear un sistema visual personalizado. La diferencia no está en añadir efectos, sino en definir jerarquías, componentes, estados y comportamiento responsive adaptados al contenido.

Funciones

Cada función debe describir:

• quién la utiliza;
• qué acción permite;
• qué datos necesita;
• qué reglas y excepciones existen;
• qué ocurre cuando falla;
• cómo se comprobará.

“Formulario de contacto” es insuficiente si no se conocen campos, destinatario, confirmación, validaciones y tratamiento de errores.

Integraciones

Pagos, reservas, CRM, facturación, inventario o email pueden depender de servicios externos. El alcance debe identificar qué datos se intercambian, quién controla las cuentas y qué sucede si el servicio no responde.

Migración

En un rediseño no basta con reconstruir las pantallas. Puede ser necesario:

• inventariar contenido;
• conservar o cambiar URLs;
• preparar redirecciones;
• migrar datos;
• mantener medición;
• revisar integraciones;
• retirar el sistema anterior.

Omitir estas tareas puede reducir la cifra inicial sin reducir el trabajo real.

Calidad técnica y pruebas

El presupuesto debe concretar qué se comprobará. Según el proyecto, puede incluir adaptación móvil, navegación por teclado, formularios, errores, rendimiento, enlaces, metadata, indexación y analítica.

“SEO técnico incluido” debería traducirse en tareas identificables: titles y descriptions, canonicals, sitemap, robots, redirecciones, estructura de encabezados o datos estructurados cuando correspondan. Ninguna de estas tareas garantiza posiciones.

Gestión y revisiones

Recopilar requisitos, coordinar contenido, revisar entregables y registrar decisiones también forma parte del proyecto. El presupuesto debe aclarar responsables, hitos, revisiones y procedimiento para solicitar cambios.

Qué debería incluir un presupuesto web

Utiliza esta lista para comprobar si una propuesta permite entender qué se entregará:

• objetivo y audiencia;
• páginas, plantillas o componentes;
• contenidos incluidos y responsable;
• diseño y grado de personalización;
• comportamiento en escritorio y móvil;
• funciones, reglas y estados;
• integraciones;
• formularios y destinatarios;
• migración y redirecciones;
• configuración SEO técnica;
• analítica y eventos;
• pruebas y criterios de aceptación;
• dominio, alojamiento y licencias;
• formación y documentación;
• soporte y mantenimiento;
• calendario e hitos;
• revisiones;
• condiciones para cambios de alcance;
• propiedad y acceso a código, cuentas, contenidos y datos;
• supuestos y exclusiones.

Si una partida relevante no aparece, pide una aclaración por escrito. No la consideres incluida por defecto.

Costes iniciales, recurrentes y de evolución

Costes iniciales

Corresponden al trabajo necesario para definir, producir, comprobar y lanzar el proyecto. Pueden abarcar requisitos, arquitectura, diseño, desarrollo, contenidos, migración, integraciones, configuración y pruebas.

Costes recurrentes

Pueden existir dominio, alojamiento, licencias, servicios externos, mantenimiento y soporte. El presupuesto debería indicar cuáles aplican, quién contrata cada cuenta, con qué periodicidad se renueva y quién conserva el acceso.

Costes de evolución

Después del lanzamiento pueden aparecer contenidos, integraciones o funciones nuevas. Conviene acordar cómo se valorarán y distinguirlas de la corrección de errores incluidos en el alcance original.

Separar estos tres grupos evita comparar una propuesta de construcción con otra que también incorpora operación y evolución.

Solución estándar, plantilla o desarrollo personalizado

La decisión se toma comparando requisitos y restricciones.

Cuándo puede encajar una solución estándar de alcance limitado

Puede encajar para una presencia sencilla con objetivo limitado, contenido preparado y pocas funciones. La comparación debe centrarse en lo que queda fuera, la titularidad de las cuentas y la posibilidad de evolucionar o migrar.

Cuándo puede encajar una plantilla

Puede resolver estructuras conocidas cuando sus límites no afectan al objetivo. Sigue necesitando contenido, configuración, adaptación móvil, accesibilidad y pruebas. La plantilla reduce determinadas decisiones; no sustituye el trabajo editorial y técnico.

Cuándo valorar desarrollo personalizado

Tiene sentido evaluar una solución propia cuando existen reglas, usuarios, integraciones o procesos que no encajan razonablemente en una alternativa estándar. La decisión debe documentar qué restricción justifica la personalización y qué mantenimiento introduce.

Cómo priorizar funcionalidades

Antes de incluir una función, responde:

1. ¿Qué objetivo apoya?
2. ¿Quién la utiliza?
3. ¿Qué ocurre si no está en la primera versión?
4. ¿Qué dependencias o riesgos introduce?
5. ¿Cómo se comprobará que funciona?

Después clasifícala:

• Imprescindible: sin ella el proyecto no cumple su objetivo mínimo.
• Deseable: aporta valor, pero puede posponerse.
• Futura: se conserva para evolución.
• Fuera de alcance: no forma parte de la entrega acordada.

Una función sin objetivo, usuario o criterio de aceptación todavía no está lista para presupuestarse.

Plantilla para pedir un presupuesto comparable

Copia y completa este esquema:

Objetivo del proyecto:

Audiencia principal:

Acción que debe completar el visitante:

Páginas o secciones necesarias:

Contenido disponible y responsable:

Funciones imprescindibles:

Funciones deseables:

Integraciones:

Idiomas:

Web o datos que deben migrarse:

Analítica o medición necesaria:

Quién revisará y aprobará:

Fecha objetivo y motivo:

Quién mantendrá la web:

Restricciones conocidas:

Elementos expresamente fuera de alcance:

No necesitas elegir tecnología antes de completarla. El proveedor puede proponer una solución después de entender el objetivo y las restricciones.

Cómo comparar dos presupuestos

Compara el alcance, no solo el total:

Una propuesta más económica puede ser adecuada si cubre lo necesario. Esta matriz ayuda a descubrir si la diferencia procede de eficiencia, de otro enfoque o de partidas no incluidas.

Cómo detectar un cambio de alcance

Una petición puede cambiar el alcance si modifica:

• el objetivo;
• los usuarios o permisos;
• las páginas o componentes;
• el contenido;
• las reglas o flujos;
• una integración;
• la migración;
• los idiomas;
• los criterios de aceptación;
• el calendario;
• el soporte;
• una exclusión acordada.

No toda modificación es una ampliación. Si el entregable incumple un criterio acordado, puede tratarse de una corrección. Si se solicita una capacidad no incluida, debe evaluarse su impacto y actualizar el alcance antes de asumirla.

Señales de un presupuesto incompleto

Pide aclaraciones cuando una propuesta:

• ofrece una cifra sin definir objetivo ni requisitos;
• utiliza términos como “completo”, “profesional” o “SEO incluido” sin tareas;
• no asigna responsable al contenido;
• menciona integraciones sin describir el flujo;
• omite costes recurrentes;
• no identifica titularidad y accesos;
• no define pruebas ni aceptación;
• mezcla correcciones con nuevas funciones;
• no explica revisiones o cambios de alcance;
• promete resultados comerciales o posiciones;
• no declara supuestos y exclusiones.

Una señal no demuestra por sí sola que el proveedor sea inadecuado. Indica qué pregunta debe resolverse antes de contratar.

Preguntas frecuentes

¿Se puede saber cuánto cuesta una web sin preparar un briefing?

Solo puede obtenerse una referencia muy amplia. Para una estimación comparable hay que definir objetivo, contenido, funciones, integraciones, migración, pruebas y mantenimiento. Las incógnitas importantes deben aparecer como supuestos, no esconderse dentro de una cifra.

¿Por qué dos presupuestos pueden ser tan diferentes?

Porque pueden valorar entregables distintos. Compara contenido, diseño, integraciones, migración, pruebas, revisiones, soporte y costes recurrentes antes de atribuir la diferencia únicamente al precio.

¿Una plantilla es suficiente para una pyme?

Puede serlo si la estructura, las funciones y la evolución previstas encajan en sus límites. La decisión debe considerar edición, integraciones, mantenimiento, portabilidad y compromisos aceptados.

¿Qué gastos pueden continuar después de publicar?

Según el proyecto, dominio, alojamiento, licencias, servicios externos, mantenimiento, soporte y evolución. La propuesta debe identificar cuáles aplican, quién los contrata y cómo se renuevan. Cualquier cifra necesita una comprobación actualizada.

¿Qué debería recibir la empresa al terminar?

El presupuesto o contrato debe definir entregables, accesos, cuentas, contenidos, documentación y servicios recurrentes. Cuando sea necesario, una persona cualificada debe revisar sus implicaciones contractuales.

¿Cuándo hace falta desarrollo personalizado?

Cuando reglas, usuarios, datos, integraciones o evolución no encajan razonablemente en una solución estándar. La personalización debe responder a una restricción documentada, no a una preferencia abstracta.

Preparar el alcance antes de pedir una valoración

No existe un precio universal para una página web porque no existe un alcance universal. La comparación mejora cuando objetivo, contenidos, funciones, integraciones, pruebas y costes recurrentes están escritos.

Puedes revisar el tipo de proyectos que desarrolla AVSISTEC en el portfolio. Si necesitas valorar una web, consulta el servicio de desarrollo web para empresas y prepara la plantilla anterior. Después, explícanos el objetivo, las funciones imprescindibles y el contenido disponible para solicitar una valoración inicial.