Mi primer proyecto para una clienta no se pareció a hacer una web para mí con un nombre y unos colores distintos.
Hasta entonces había construido apuntes, ejercicios y herramientas nacidas de necesidades propias. Si algo quedaba pendiente, la consecuencia la asumía yo. Con la web de Patricia Pólvora, cada página debía ayudar a explicar un trabajo profesional que no era el mío. Ahí cambió la responsabilidad.
Patricia trabaja en consultoría de impacto social, es formadora oficial de Social Value International en español y dirige The Social Consulting Agency. La web tenía que reunir servicios, informes, publicaciones, prensa, formaciones, charlas y formas de contacto sin convertir su trayectoria en un menú imposible de recorrer.
El resultado fue un sitio en Astro con más de 17 páginas indexables. El número importa menos que lo que obligó a pensar. Ya no bastaba con que cada página quedara bien por separado. La estructura tenía que servir a quien llega por primera vez, a quien busca un servicio concreto y a quien necesita ampliar el sitio más adelante.
Entender el encargo fue ordenar una trayectoria
No partía de un producto con tres pantallas ni de una landing con un único mensaje. Había servicios de consultoría distintos, informes descargables, contenido editorial, una historia de emprendimiento, apariciones en prensa y una reserva de contacto.
Antes de entrar en componentes, necesitaba entender qué papel tenía cada bloque. Algunas cosas merecían una página propia porque respondían a una búsqueda o a una decisión concreta. Otras ganaban sentido al estar agrupadas. La página de inicio no podía cargar con toda la explicación, pero sí debía orientar hacia lo importante.
Ese trabajo cambió mi manera de ver la arquitectura de información. Organizar más de 17 páginas no consistía en repetir una plantilla muchas veces. Consistía en decidir qué necesita encontrar cada persona y en qué orden. Cuando una web tiene tanto contenido, una mala jerarquía no se nota solo en la navegación. También hace más difícil escribir, mantener y posicionar cada página.
Diseñar una base para que el sitio no dependiera de la memoria
Elegí Astro, TypeScript y Sass porque necesitaba una base rápida, controlable y fácil de ampliar. El objetivo no era utilizar una tecnología concreta por lucirla. Quería evitar que, al añadir una página o cambiar una sección, hubiera que recordar dónde estaba cada estilo, metadato o dato de contacto.
Organicé los estilos con Sass 7-1, centralicé datos que se repetían y apoyé las páginas en componentes reutilizables. Eso no elimina el trabajo de un sitio grande, pero evita que el proyecto se convierta en una colección de excepciones.
La decisión también tenía una contrapartida. Un sitio estático da mucho control al desarrollar, pero obliga a pensar cómo se hará cada actualización. Esa tensión entre una base técnica limpia y la autonomía de quien mantiene el contenido es una de las razones por las que no elegiría Astro o WordPress por costumbre. La herramienta tiene que encajar con el mantenimiento real, no solo con el día de la entrega.
SEO y accesibilidad dejaron de ser extras
En un proyecto personal es fácil dejar el SEO técnico, los textos alternativos o una navegación cuidada para cuando “haya tiempo”. Al trabajar para Patricia, esa forma de priorizar ya no tenía sentido. La web necesitaba poder encontrarse y poder usarse desde el principio.
La estructura semántica, la navegación en escritorio y móvil, los desplegables accesibles y el menú de tipo panel formaban parte del producto. No eran una capa de revisión al final. También preparé metadatos por página, canonicals, Open Graph, datos estructurados, sitemap dinámico y reglas específicas para las páginas legales.
Buena parte de ese trabajo se apoyaba en algo muy simple. Cada página tenía que tener una función clara. Una página de un servicio no puede posicionarse igual que una página de prensa, y una sección de informes no debería tener los mismos metadatos que una página de contacto. El trabajo de SEO técnico que después apliqué en mi portfolio se volvió más concreto aquí porque había contenido y objetivos profesionales reales detrás de cada URL.
Publicar también era parte del encargo
El momento que más me sacó de la zona conocida no fue escribir un componente. Fue poner la web en producción.
La desplegué en Vercel, configuré el dominio profesional de Patricia y gestioné las redirecciones necesarias para que el sitio arrancara correctamente. Era la primera vez que afrontaba esa parte completa de un proyecto para otra persona.
Ese proceso me dejó una idea muy clara. Una web no está terminada cuando funciona en local. Está terminada cuando carga con su dominio, mantiene sus rutas, presenta su contenido correctamente y alguien puede usarla sin saber nada del repositorio que hay detrás.
Las dificultades no eran solo técnicas
La parte difícil de un encargo así no se reduce a resolver errores de código. Había que tomar decisiones con información incompleta, priorizar contenido muy distinto y evitar que una página nueva desordenara todo lo anterior.
También tuve que aceptar el límite evidente de ser mi primer proyecto de este tipo. Tenía experiencia construyendo webs y podía investigar lo que no conocía, pero no podía fingir que ya había pasado por todos los escenarios de una entrega profesional. El dominio, el despliegue y las redirecciones fueron ejemplos concretos de cosas que tuve que aprender mientras el proyecto avanzaba.
La forma de salir de ahí no fue improvisar ni añadir tecnología por si acaso. Fue dividir los problemas, revisar cada parte y volver al propósito de la web. Cuando dudaba entre dos soluciones, intentaba hacer una pregunta más útil que “cuál queda mejor”. ¿Qué ayuda a Patricia a explicar su trabajo y qué podrá mantenerse sin rehacer el sitio dentro de unos meses?
Qué haría distinto ahora
No cambiaría el aprendizaje por intentar que todo saliera perfecto a la primera. Sí empezaría antes algunas conversaciones y documentos que ahora valoro más.
Definiría desde el inicio qué contenido va a cambiar con frecuencia, quién se ocupará de esos cambios y qué autonomía necesita la persona que recibe la web. Esa respuesta influye en la arquitectura tanto como el diseño. También dejaría por escrito una revisión de lanzamiento con rutas, formularios, metadatos, responsive, accesibilidad y analítica. No para burocratizar un proyecto pequeño, sino para que lo importante no dependa de acordarse en el último momento.
Y reservaría una revisión posterior a la publicación. El primer día online permite comprobar cosas que el entorno local no enseña y abre preguntas reales sobre contenido, navegación y mantenimiento.
El aprendizaje que me llevé
Este proyecto confirmó algo que ya intuía con mis aplicaciones y apuntes. Construir es una forma de aprender, pero un proyecto para otra persona te obliga a aprender con más cuidado. El código sigue importando, pero pasa a convivir con claridad de mensaje, límites de mantenimiento, búsqueda orgánica, accesibilidad y responsabilidad al publicar.
No salí del proyecto pensando que ya sabía construir cualquier web profesional. Salí con una referencia mucho más concreta de lo que significa entregar una. Hoy puedo mirar decisiones de arquitectura, SEO o despliegue desde una experiencia real y también reconocer qué preguntas conviene hacer antes de abrir el editor.
El detalle técnico, las páginas y el resultado están recogidos en el caso de estudio de Patricia Pólvora.