Alta Group tiene 23 años de obra real y ninguna forma de mostrarla online. Este es el registro, con evidencia — commits, código y contenido real — de cómo esa trayectoria se convirtió en un sitio de 25+ páginas con un sistema de portfolio propio.
Alta Group tenía la trayectoria y la evidencia de trabajo real para generar confianza en su público — pero ningún canal digital capaz de comunicarla.
Más de 23 años de obra, referencias verificables con teléfono de administración de consorcio, clientes como el Instituto Argentino del Petróleo y el Gas. Todo eso vivía en una carta institucional en PDF y una carpeta de fotos de celular sin curar — invisible para cualquiera que buscara la empresa antes de contratarla.
El problema no era estético en primer término: era de acceso. La confianza estaba construida en el mundo físico, obra por obra, y no tenía forma de trasladarse a una búsqueda en Google o a una conversación por WhatsApp.
A eso se sumaban problemas descubiertos recién al entrar en el material de origen: contenido duplicado en el propio diseño de Figma (dos fichas de proyecto distintas compartían el mismo texto, incorrecto para una de las dos obras reales) y un formulario de contacto cuya lógica de confirmación dependía de un dominio fijo — un bug capaz de perder leads en silencio.
Sin sitio previo. El insumo real era una carpeta de presentación comercial en PDF —pensada para administradores de consorcio, no para la web— y un Figma que, como se vería después, traía sus propios errores de contenido.
No hubo un "sitio anterior" que rediseñar. Hubo que construir, desde material analógico, una arquitectura completa: Home → hub de categoría → ficha de detalle, repetida de forma consistente para Servicios y para Proyectos.
Cinco colores, una tipografía, una escala fluida con clamp(). Sin frameworks de diseño ni librerías visuales — variables CSS propias, aplicadas sin excepción en 25+ páginas.
La única desviación del sistema —un celeste (#D0E5FF) en las tarjetas de datos del Home— está documentada en el propio CSS como "excepción visual pedida por el cliente", no como una inconsistencia sin explicar. Es una diferencia pequeña, pero revela un principio: nada en el sistema es arbitrario, y lo que no sigue la regla queda señalado como tal.
Dos pares de fichas de proyecto compartían el mismo párrafo y bullets en el diseño original — texto que no correspondía a la obra real en al menos una de cada par.
Redactar copy propio y diferenciado para esas fichas, dejando una nota explícita en el código señalando qué es contenido provisional.
Las 13 fichas muestran información coherente con la obra real — evitando publicar un dato incorrecto frente a administradores que pueden identificar el edificio.
La confirmación post-envío dependía de una URL absoluta hardcodeada. Fuera de ese dominio exacto, el envío terminaba en un error silencioso.
Interceptar el submit con fetch() y redirigir con ruta relativa, resuelta por el propio JavaScript.
El formulario funciona igual sin importar en qué dominio se sirva el sitio — protege un lead que, de otro modo, se habría perdido sin que nadie lo notara.
13 fichas casi idénticas en estructura, codificadas a mano, son 13 archivos a mantener en paralelo.
Una plantilla dinámica (proyecto.html) + un archivo de datos centralizado, con instrucciones embebidas para sumar un proyecto nuevo.
Agregar la obra #14 es una tarea de datos, no de desarrollo — el portfolio queda abierto a crecer sin reescritura.
Un tercero aportó ajustes estéticos y de mobile en una rama separada, en un contexto de desacuerdo de pago (así consta en el propio mensaje de commit).
No fusionar esos cambios a main, y resolver el mismo tipo de problema con una implementación propia, minutos después.
El entregable final contiene un único autor de responsabilidad sobre el código, con el problema igualmente resuelto.
Servicios y Proyectos comparten exactamente la misma lógica de navegación: hub con grilla → ficha de detalle. Quien entiende cómo moverse por uno, ya sabe moverse por el otro — una decisión que reduce la carga cognitiva sin necesitar explicación.
El WhatsApp flotante está presente en cada página del sitio, en paralelo al formulario formal: cubre tanto a quien prefiere completar un formulario estructurado como a quien quiere escribir directamente, sin forzar una sola vía de contacto.
Cada ficha de proyecto se renderiza desde una única plantilla, a partir de un objeto de datos centralizado. La foto principal, el tipo de obra, la fecha y la galería completa (entre 7 y 27 fotos por proyecto) son reales — provistas por el cliente y optimizadas a WebP.
HTML5, CSS3 y JavaScript ES6+ vanilla. Cero dependencias de build, cero librerías de UI externas.
Navegación de galería por teclado (flechas, Escape, click fuera para cerrar) — no solo funcional con mouse.
El paso de scroll se calcula del ancho real de una tarjeta, no de un pixelaje fijo — queda alineado en cualquier ancho de pantalla.
Si JavaScript falla, el contenido queda visible por defecto. Ninguna mejora visual puede romper la lectura básica.
Estados de foco visibles en cada control interactivo. prefers-reduced-motion respetado de forma explícita — quien lo pide a nivel sistema operativo no ve ninguna animación de aparición al scroll. Texto alternativo específico por imagen, nunca genérico.
El dropdown de "Servicios" tuvo al menos dos implementaciones antes de la definitiva: la primera dejaba un hueco de hover que cerraba el menú a mitad de camino. La solución final está documentada en el propio CSS, incluyendo por qué el primer intento no funcionaba.
Ajustes de precisión sub-pixel, revisados sin apuro cerca del cierre del proyecto: un commit registra, sin ironía, "dos px de variación en topbar, pero queda mejor". Es la clase de detalle que nadie nota cuando está bien resuelto.
Verificado, no asumido: auditoría de responsive con Playwright (commit documentado), conversión de ~280 fotos a WebP organizadas por proyecto, y redacción de copy propio para dos fichas sin contenido válido de origen.
33 commits con timestamp real. Se muestran tal como quedaron registrados — incluyendo los ocho "finales" que precedieron al cierre real, y el episodio de una rama que no se integró.
Sin Analytics, Search Console ni Lighthouse conservados en el proyecto, no hay métrica de negocio para mostrar todavía. Lo que sigue es evidencia de proceso, verificable en el propio repositorio — no de resultado en producción.
La misma identidad —logo, paleta, nombre— pasa de vivir en un PDF de venta a aplicarse con consistencia en 25+ páginas.
De pedir el PDF por WhatsApp a navegar 13 obras reales con galería propia, sin salir del sitio.
El sistema de datos para proyectos convierte al portfolio en algo que crece sin desarrollo adicional.
Sin datos de conversión aún — pero el bug que podía perder leads en silencio quedó corregido antes de la entrega.
Alta Group no necesitaba una identidad nueva — la tenía. Necesitaba que su trayectoria real fuera accesible para alguien que la busca por primera vez desde un buscador o desde el WhatsApp de un vecino. Este proyecto demuestra la capacidad de tomar material incompleto —un Figma con errores, un PDF institucional, fotos sin procesar— y convertirlo en un producto digital consistente, accesible y pensado para durar más allá de la entrega, en un plazo de siete días de trabajo documentado.