Reconstruir BRVSCU desde cero, en dos etapas

• ·El sitio está en producción, en el mismo hosting de siempre, con un build estático propio en vez de WordPress.
• ·El estudio puede editar y actualizar contenido sin depender de terceros ni de plugins rotos.
• ·LCP bajó de 44s a 9.3s en producción real; sigue siendo trabajo pendiente por la dependencia de CDNs externas.
• ·SEO técnico construido desde cero: sitemap, metadata único por página, datos estructurados, canonical + hreflang.
• ·Problemas reales de accesibilidad corregidos (foco de teclado, contraste, jerarquía de headings) mediante auditoría manual con heurísticas de Nielsen y WCAG 2.1 AA.
• ·Feedback positivo del cliente tras el deploy, con dos ajustes puntuales de contenido resueltos rápido.

01

El problema original: una web inmantenible

El sitio de BRVSCU llevaba más de cinco años sin cambios, desarrollado por una agencia externa sobre WordPress. Con el tiempo quedó desactualizado en contenido y diseño, y surgieron problemas técnicos serios: dificultad para recuperar los accesos y, una vez recuperados, imposibilidad de editar contenidos por conflictos entre plugins. Consulté con desarrolladores senior y no fue posible destrabarlo. La conclusión fue clara: no era viable mantener ni escalar la web existente.

02

Primera solución: reconstruir con ChatGPT como copiloto

Desarrollé una web nueva desde cero: HTML semántico, CSS + Bootstrap para estructura y responsive, JavaScript para interacciones puntuales — sin plugins ni builders, para mantener el proyecto simple y controlable. Usé ChatGPT como compañero de trabajo para retomar fluidez en código que hacía tiempo no escribía a diario, revisando y ajustando cada fragmento generado en vez de aceptarlo sin criterio. Reescribí todo el contenido con foco en claridad y SEO, y sumé una sección de publicaciones para que el estudio pudiera cargar artículos propios. El resultado funcionó, pero el proceso tuvo fricción técnica real: cinco páginas en español duplicadas en cinco archivos HTML más para inglés, sin ningún paso de build — cualquier cambio de navegación o pie de página había que replicarlo a mano diez veces.

03

Por qué lo retomé, y con qué enfoque

Tiempo después volví al proyecto, esta vez con mi perfil de Product Designer más consolidado y con Claude y Claude Code como herramientas de trabajo. El objetivo no fue rediseñar todo desde cero — el cliente quería conservar la identidad visual — sino modernizar la base técnica y ajustar el diseño donde hiciera falta, con el mismo rigor que vengo aplicando en mi propio portfolio. Antes de tocar código, usé Claude para pensar el proyecto: evalué frameworks (descarté Next.js por sobredimensionado para un sitio institucional de cinco páginas, y Eleventy por no aportar ninguna ventaja real sobre Astro) y elegí Astro por ser static-first y tener soporte de internacionalización nativo. Definí la estrategia de URLs — español sin prefijo, donde ya había posicionamiento SEO ganado, e inglés bajo /en/ — priorizando ese SEO existente por sobre la simetría estructural. Y, a pedido explícito del cliente, descarté sumar un formulario de contacto.

04

Construcción e iteración con Claude Code

Con el enfoque definido, construí e iteré con Claude Code: un sistema completo de tokens (color, tipografía, espaciado) reemplazando valores sueltos y repetidos; un rediseño de la sección Áreas de práctica, que pasó de una grilla de 16 botones sin jerarquía a una página de referencia con índice sticky y detalle expandible, con paridad completa en inglés; reemplacé el menú hamburguesa mobile por una bottom navigation fija; y rediseñé la banda de CTA y el footer. De paso encontré y corregí un bug de contenido real que llevaba tiempo sin detectarse: el modal de uno de los socios tenía el LinkedIn de otro copiado por error, en ambos idiomas.

05

Auditoría de diseño y accesibilidad

En este proyecto la auditoría fue manual, guiada por heurísticas de Nielsen y WCAG 2.1 AA. Encontré y corregí varios problemas reales: un bug de foco de teclado que quedaba "pegado" después de cerrar un modal con mouse, resuelto con un patrón propio que distingue si el usuario navega con teclado; contraste y jerarquía invertidos en los links de los modales, resuelto pasando de depender solo del color a un gris con subrayado permanente; falta de un h1 único por página y jerarquía de headings desordenada en los modales de Áreas de práctica; y ausencia de skip-link y de foco visible en el CTA principal, ambos agregados.

06

Performance y SEO

Auditar performance con Lighthouse mostró el problema dominante del sitio original: un LCP de 44 segundos en la medición inicial, producto de depender de dos CDNs externas (Bootstrap y AOS) para poder pintar la página. Tras la migración, el LCP en producción real bajó a 9.3 segundos — una mejora real y grande, aunque todavía alto para estándares actuales: el sitio sigue usando esas mismas dependencias externas, ahora dentro de un build propio con Astro, así que es trabajo pendiente que no doy por cerrado. En SEO construí lo que no existía: sitemap y robots.txt generados automáticamente en el build, título y descripción únicos por página (antes las cinco páginas compartían el mismo título y descripción, carácter por carácter), Open Graph y Twitter Cards, datos estructurados JSON-LD (schema.org/LegalService) con la información real del estudio, y canonical + hreflang correctos para ambos idiomas. Sumé también Microsoft Clarity para dejar de asumir cómo se usa el sitio y empezar a medirlo — es reciente, todavía no hay insights de comportamiento para compartir, pero es el mismo criterio que ya aplico en mi propio portfolio.