Para elegir qué web necesitas, describe la tarea que debe completar quien la visita y qué ocurre después. Los nombres —corporativa, catálogo, tienda, plataforma— orientan, pero no fijan por sí solos el alcance.
Una web pequeña puede tener una función compleja. Una web extensa puede estar formada principalmente por contenido. Esta diferencia explica por qué contar páginas no basta para comparar propuestas.
Una clasificación útil para conversar
La tabla siguiente es una clasificación práctica de encargos, no una taxonomía oficial. Una misma web puede combinar varios tipos.
| Tipo de web | Tarea principal | Qué cambia el alcance |
|---|---|---|
| Presentación y servicios | Entender una actividad, comparar servicios y contactar | Redacción, ejemplos, idiomas, formularios y forma de editar |
| Catálogo | Encontrar y revisar elementos | Número de fichas, campos, filtros, búsqueda e importación |
| Publicación o biblioteca | Consultar y relacionar contenidos | Tipos de contenido, autores, revisión, archivo y navegación |
| Captación para una acción | Completar una solicitud concreta | Campos, validación, destino, seguimiento y errores |
| Tienda o contratación online | Elegir, pagar y recibir un producto o servicio | Stock/disponibilidad, impuestos, pagos, cancelaciones y operación |
| Área privada o aplicación | Trabajar con datos y reglas de forma recurrente | Identidad, roles, permisos, estados, integraciones y continuidad |
Que una web tenga un formulario no la convierte en una aplicación compleja. Que una aplicación se abra en el navegador no la convierte en un encargo de “cinco páginas”.
La distinción técnica entre contenido estático y dinámico ayuda a entender de dónde sale lo que se muestra: un servidor puede entregar archivos preparados o generar una respuesta a partir de datos y una petición. No describe por sí sola la utilidad ni la calidad del proyecto. MDN explica el modelo cliente-servidor, consultado el 10/09/2026.
El mismo negocio con tres alcances distintos
Usaremos Estudio Ladera, una identidad ficticia de interiorismo creada para este material. Estos escenarios son ejercicios de alcance; no describen necesidades de un cliente real.
Escenario 1 Una web para entender y consultar
La persona lee los tres servicios, revisa dos propuestas ilustrativas y abre un formulario con el servicio seleccionado.
El trabajo principal está en explicar la oferta, organizar contenido, diseñar el recorrido y comprobar que la consulta se entrega o informa del error. No necesita cuentas, pagos ni filtros para cumplir esa tarea.
En la demo de Ladera, la confirmación del formulario es local y explícitamente simulada. Una web real necesitaría además destinatario, proveedor, tratamiento de datos y prueba de entrega.
Escenario 2 Un catálogo de propuestas
Ahora imaginemos que hay decenas de propuestas y que se quieren filtrar por tipo de espacio, materiales y necesidades. Cada ficha comparte campos y relaciones.
El cambio importante no es añadir veinte enlaces al menú. Hay que definir un modelo de ficha, mantener datos consistentes, resolver filtros y búsquedas sin coincidencias y facilitar la edición. También hay que decidir si esos filtros generan URLs públicas útiles o simplemente estados de navegación.
La necesidad nueva puede resolverse con un gestor de contenidos adecuado. No obliga a crear una aplicación con cuentas si todas las personas consultan la misma información.
Escenario 3 Una aplicación para preparar un proyecto
En otro alcance, la persona guarda estancias, anota medidas y preferencias, compara alternativas y comparte decisiones con otra persona.
Aquí el recorrido depende del estado de los datos. Hay que decidir quién puede ver y editar, cómo se guarda, qué ocurre ante cambios simultáneos y cómo se recupera el acceso o se exporta información.
El presupuesto y las pruebas tendrán que incluir esas reglas. Una pantalla de acceso y un panel visual no prueban que el aislamiento o la continuidad funcionen.
Describe la acción completa
Una forma de descubrir alcance oculto es escribir una función con cinco elementos:
Quién actúa → qué información utiliza → qué cambia → quién recibe el resultado → qué ocurre si falla.
“Reservar una cita” puede significar cosas distintas:
- Enviar una petición que una persona confirma después.
- Mostrar una agenda externa ya operativa.
- Calcular disponibilidad propia, bloquear plazas y permitir cancelaciones.
- Cobrar, conciliar el pago y devolverlo cuando corresponda.
El botón puede llevar la misma palabra en todos los casos. Las dependencias, responsabilidades y pruebas son diferentes. El briefing debe dejar claro cuál se espera.
No conviertas posibilidades futuras en funciones incluidas. Si la reserva está por decidir, escríbela como pendiente y pregunta qué cambio supondría cada alternativa.
Contenido y edición también son alcance
El número de páginas importa cuando representa trabajo real: recopilar contenido, redactar, estructurar, diseñar variantes, migrar o revisar información.
Una ficha puede compartir plantilla con otras sin que su contenido aparezca por arte de magia. Del mismo modo, que exista un CMS no significa que cualquier persona pueda modificar todo sin consecuencias.
Para definir edición, responde:
- ¿Quién cambiará los textos y con qué frecuencia?
- ¿Añadirá nuevos elementos o solo corregirá los existentes?
- ¿Necesita revisar antes de publicar?
- ¿Qué partes debe poder modificar y cuáles deberían permanecer estables?
- ¿Qué ocurrirá si quien edita comete un error?
La guía de elección de CMS propone una prueba con estas tareas. La elección debe resolver el trabajo editorial de tu web, no imitar la tecnología de otra empresa.
La primera entrega necesita límites
Una primera versión puede ser útil y estar completa aunque no incluya todas las posibilidades futuras. Su tarea principal tiene que funcionar de principio a fin.
En Ladera, una entrega completa del escenario informativo incluye todos los servicios acordados, contenido, navegación, móvil, estados del contacto y continuidad. No se convierte en completa por tener una portada bonita si los enlaces interiores o el formulario no funcionan.
Puedes ordenar el alcance así:
| Estado | Ejemplo | Consecuencia para la propuesta |
|---|---|---|
| Dentro | Tres servicios con detalle y contacto contextual | Se estima, construye y comprueba |
| Fuera | Reservas con disponibilidad y pago | No se presenta como función incluida |
| Pendiente | Quién editará las propuestas | Se explica qué decisión y prueba faltan |
| Posible ampliación | Área para guardar un proyecto | Se conserva como opción, con alcance propio |
“Preparada para crecer” necesita una explicación concreta: estructura del contenido, exportación, arquitectura o límites. No es una promesa de que añadir cualquier función será sencillo o barato.
Cuándo pedir una propuesta de aplicación
Pide que se valore como aplicación cuando el trabajo principal consiste en crear o modificar datos, aplicar reglas propias o gestionar acceso de varios perfiles. Lleva ejemplos de tareas y errores, además de pantallas.
Eso no implica que haya que desarrollar todo a medida. Puede existir una solución estándar que resuelva la necesidad; la comparación debe incluir adaptación, continuidad y costes de uso. La comparación entre software propio, SaaS y no-code amplía esa decisión.
Si lo que necesitas es explicar una actividad y facilitar una consulta, empieza por concretar una buena web. Añadir cuentas o automatización sin un trabajo claro puede aumentar el mantenimiento sin aportar utilidad.
Convierte la decisión en un briefing
Al terminar, deberías poder describir:
- La persona y la tarea principal.
- El contenido que necesita.
- Las acciones y los datos que cambian.
- La edición y operación posteriores.
- Lo incluido, lo excluido y lo pendiente.
- Un caso que debe completarse y otro que debe fallar de forma comprensible.
El briefing web cumplimentado muestra cómo queda esa conversación por escrito. Si quieres preparar tu caso, usa el constructor de briefing y elige web o aplicación según la tarea que acabas de definir. La guía para crear y encargar una web profesional conecta esta decisión con contenido, presupuesto, construcción y entrega.