Cómo gestionamos un proyecto web: fases, plazos y entregables

Un proyecto web no se retrasa porque falte una herramienta. Se retrasa cuando nadie sabe qué se está decidiendo, quién tiene que aprobarlo o qué significa que una fase está terminada.

Por eso en Reveled no empezamos por Figma ni por el código. Empezamos por reducir incertidumbre. Este es el proceso que sigue un proyecto desde el primer mensaje hasta el soporte posterior al lanzamiento.

Las fases, sin nombres inflados

Fase	Qué decidimos	Qué recibe el cliente
Diagnóstico	Si podemos ayudar y cuál es el problema real	Alcance inicial y próximos pasos
Propuesta	Qué hacemos, qué no y en qué plazo	Propuesta con precio, entregables y límites
Estructura	Qué páginas existen y qué debe conseguir cada una	Arquitectura y esquema de contenidos
Dirección visual	Cómo debe verse y por qué	Diseño de inicio y páginas clave
Desarrollo	Cómo se construye y con qué tecnología	Entorno de preview funcional
Revisión	Qué falta para considerar el trabajo terminado	Correcciones trazables y aprobación
Lanzamiento	Qué debe funcionar en producción	Web publicada y comprobada
Soporte	Qué ocurre si aparece un fallo después	Quince días de seguimiento incluidos

La tabla parece simple porque debe serlo. Un proceso útil no necesita cuarenta estados. Necesita que cada fase cierre una decisión antes de abrir la siguiente.

1. Diagnóstico: primero decidimos si hay encaje

Cuando alguien contacta, la primera pregunta no es qué color le gusta. Es qué problema intenta resolver.

Puede ser una web que ya no representa al negocio. Un servicio difícil de explicar. Un ecommerce que recibe visitas pero no vende. Una plataforma con demasiada información y sin una ruta clara. Si no entendemos el problema, cualquier presupuesto sería una cifra puesta encima de una suposición.

También comprobamos si somos la opción correcta. Hay proyectos que no son para Reveled. Si la prioridad absoluta es publicar en tres días o conseguir el precio más bajo posible, lo decimos antes de hacer perder tiempo a nadie.

Salida de esta fase: problema definido, responsables identificados y decisión de continuar o no.

2. Propuesta: lo que entra y lo que no

Si hay encaje, preparamos una propuesta que responde cuatro cosas:

1. Qué vamos a construir.
2. Qué no está incluido.
3. Cuánto cuesta.
4. Cuándo estará listo.

El alcance no es una formalidad. Es lo que impide que un proyecto de cinco páginas termine convertido, sin decisión explícita, en una plataforma con área privada, tres idiomas y automatizaciones.

La propuesta incluye dos rondas de revisiones. Si aparece una tercera porque el alcance cambió o se reabre una decisión ya aprobada, se presupuesta aparte. No como castigo, sino para que el tiempo y el coste sigan siendo visibles.

Salida de esta fase: alcance, precio, calendario, entregables y criterios de aprobación.

3. Estructura: antes de diseñar, ordenamos

El diseño empieza en texto.

Definimos qué páginas necesita la web, qué pregunta responde cada una y cuál es la acción que esperamos del usuario. A veces basta un esquema. Otras veces hace falta un wireframe sencillo. Lo importante es que la arquitectura pueda discutirse sin que los colores, las fotos o las animaciones distraigan de la decisión principal.

Cambiar un esquema cuesta minutos. Cambiar una interfaz completa después de haber aprobado la estructura cuesta días.

Aquí también aparece el contenido. Si una página no tiene una función clara, se elimina o se integra en otra. No construimos rutas porque «todas las webs tienen una».

Salida de esta fase: mapa de páginas, jerarquía de contenidos y objetivo de cada ruta.

4. Dirección visual: suficiente para decidir con criterio

Diseñamos el aspecto del inicio y dos o tres páginas clave antes de pasar a desarrollo. Eso permite validar la tipografía, el color, el ritmo, los componentes y la relación entre contenido e imagen en situaciones reales.

No enseñamos una portada aislada que funciona como póster pero no demuestra cómo se comporta el sistema. Elegimos páginas que obliguen al diseño a resolver problemas distintos: navegación, contenido largo, formularios, listados o fichas de producto, según el proyecto.

Si el alcance exige todas las pantallas diseñadas antes de desarrollar, se hace. En otros proyectos es más eficiente aprobar el sistema visual y construir el resto con esa base.

Salida de esta fase: dirección visual aprobada y componentes suficientes para desarrollar sin improvisar.

5. Desarrollo: un preview desde el principio

El código vive en Git desde el primer commit. El stack se decide antes de empezar y responde al proyecto, no a una preferencia automática:

• Astro para webs corporativas, portfolios y contenido donde el rendimiento debe ser el punto de partida.
• Next.js cuando existe lógica de aplicación, estados complejos o integraciones que lo justifican.
• WordPress cuando el cliente necesita editar con autonomía y su caso encaja mejor con ese ecosistema.

Durante el desarrollo hay un entorno de preview. El cliente no espera hasta el último día para descubrir cómo funciona la web. Puede comprobar avances reales sin tocar producción.

Cada revisión se hace sobre una versión identificable. Así evitamos el clásico «esto antes estaba distinto» sin saber en qué momento cambió.

Salida de esta fase: web funcional en preview, conectada a sus contenidos e integraciones.

6. Revisión: corregir sin volver al principio

Una revisión no es una lluvia de ideas nueva. Es comprobar si lo construido cumple lo aprobado.

Agrupamos los comentarios por ronda para evitar correcciones contradictorias enviadas por varios canales. El cliente sabe qué está pendiente y nosotros sabemos cuándo una decisión está cerrada.

Antes del lanzamiento revisamos, como mínimo:

• navegación y enlaces;
• formularios y correos;
• versión móvil;
• títulos, descripciones y canonical;
• indexación y sitemap;
• imágenes y textos finales;
• analítica y eventos acordados;
• páginas de error y redirecciones necesarias.

Salida de esta fase: aprobación de lanzamiento y checklist técnico completado.

7. Lanzamiento: publicar no es pulsar un botón

El despliegue es automático siempre que el proyecto lo permite, pero la automatización no sustituye la comprobación.

Después de publicar verificamos la URL real, no solo el resultado del build. Comprobamos que el servidor entrega la versión nueva, que las rutas importantes responden correctamente y que formularios, metadatos y recursos funcionan en producción.

Una compilación correcta no demuestra que el despliegue haya terminado bien. La verificación pública sí.

Salida de esta fase: web publicada, comprobada y accesible en su dominio definitivo.

8. Soporte: los primeros quince días también son proyecto

El lanzamiento no cierra el trabajo de golpe. Incluimos quince días de soporte posterior para detectar incidencias que solo aparecen con tráfico, dispositivos reales o el uso cotidiano del equipo.

Al terminar, el cliente conserva el repositorio, la documentación básica y los accesos que correspondan. Si después necesita mantenimiento, evolución o contenido, se plantea como una fase nueva con alcance propio.

Las herramientas tienen un papel secundario

Usamos Obsidian para conservar contexto y decisiones, Todoist para las tareas y GitHub para el historial del código. Cuando un cliente o un equipo necesita visibilidad compartida, puede entrar Notion.

Pero ninguna de esas herramientas es el proceso.

El proceso es saber qué se decide en cada fase, quién debe aprobarlo y qué evidencia demuestra que está terminada. Si una herramienta añade más fricción que claridad, se elimina.

Eso es también lo que permite trabajar más rápido sin recortar calidad: menos transferencias, menos decisiones repetidas y menos trabajo que debe rehacerse.

Si quieres ver cómo ese proceso se traduce en trabajos reales, puedes revisar el portfolio de Reveled y el alcance de nuestro servicio de diseño web. Y si todavía no sabes si necesitas rediseño, desarrollo o simplemente ordenar lo que ya tienes, el análisis gratis sirve precisamente para tomar esa decisión antes de gastar en construir.