Camino a Vector 2.0

Llevamos meses con la cabeza baja y los teclados sonando, construyendo sistemas de alto rendimiento para el resto. Mientras tanto, nuestra propia vitrina digital, el sitio de Vector, se había convertido en un pequeño museo. Estaba bien resuelto a nivel técnico, pero era un collage de cuatro generaciones de ideas, dos marcos de UI distintos y tres procesos de build y despliegue separados.

La deuda técnica no era solo alta; era una torre de “eso lo arreglamos después.”

Con el lanzamiento de nuestras propias herramientas (beads (bd), bdui, y el estreno de nuestro sistema de CRM/Facturación Orion), decidimos apuntar el cañón hacia nosotros. No fue solo un rediseño; fue aplicar el ethos de desarrollo tipo guerrilla con el que trabajamos. También presentamos una nueva identidad visual: el logo de Vector Costa Rica 2026, que ahora ancla la barra de navegación, el footer y los puntos de contacto clave. Es una marca limpia que encaja con la dirección que estamos tomando: clara, reconocible y hecha para durar.

---

El factor nerd: por qué hacemos esto

Me gusta ser transparente con este proceso porque cuenta nuestra historia mejor que cualquier texto de marketing. Detrás de los posts de LinkedIn y el “tecno-jerga,” yo (Lorenzo) y mi socio somos dos nerds a los que en serio les gusta el oficio.

Suelo meterle al menos 12 horas diarias a estos proyectos. No nos interesa exprimir dinero a la gente ni sumar funciones por postureo. Queremos entregar tecnología que se sienta tangible y soporte que exista cuando se necesite. Vector siempre quiso ser un escalón, una forma de tomar una idea e implementarla de punta a punta: desde definir stacks y colores hasta arquitectura, CI/CD y soporte retroactivo a largo plazo.

Esta actualización es, por fin, alinear nuestro propio sitio con ese ethos de diseño.

---

La inmersión técnica

Queríamos que el sitio se sintiera coherente y predecible. Eso exigía nombrar los problemas y arreglarlos de raíz.

1. La muerte del ruido en hover

Al principio caímos en la trampa de “más hover = más pulido.” Teníamos animaciones de hover en tarjetas, badges y pastillas decorativas. En una demo se veía vivo; en la práctica era una pesadilla de UX. No se distinguía qué era un enlace real y qué era solo una caja “bonita” reaccionando al cursor.

La regla: Hover solo en elementos interactivos (botones, enlaces, toggles, nav, enlaces del footer).

La ejecución: Quitamos hover de tarjetas de estadísticas, ítems de timeline, contenedores del carrusel, tarjetas del blog y de UI no interactiva como los badges de habilidades y los wrappers del CTA. Si no hace algo, no se mueve.

El resultado: Una interfaz estable, profesional e intencional. Lo clicable responde; lo demás se queda quieto.

2. Resolviendo el “hover jank”

Notamos un parpadeo molesto cuando el cursor llegaba al borde de un botón. Usábamos scale en hover. El botón crecía, el borde se pasaba del cursor, el hover “terminaba,” el botón volvía a su tamaño y el ciclo se repetía al infinito.

La solución: Dejamos de usar scale en elementos interactivos y pasamos a transiciones de opacidad (p. ej. iconos al 80%, 100% en hover). La opacidad no cambia la “caja” del elemento, así que el parpadeo desapareció. Reservamos el scale para detalles no interactivos (como las imágenes de las tarjetas del blog) donde el usuario no está intentando hacer clic.

3. La guerra de cascada de los iconos

Estábamos en una pelea constante con el CSS para mantener los iconos consistentes en modo claro y oscuro. En hover, a veces los iconos tomaban el color equivocado, o teníamos que emparejar a mano las versiones claro/oscuro en cada plantilla.

La solución: Creamos un componente estándar ButtonIcon. Usa currentColor, así que el icono hereda automáticamente el color del texto del botón. Se acabaron las sobreescrituras globales de tema y los pares claro/oscuro. Un componente, un solo lugar para cambiar las cosas. Migramos todos los botones y enlaces (flotante de contacto, CTAs del hero, modales, carruseles) a usarlo. Los iconos se comportan igual en todas partes y respetan el modo oscuro sin lógica extra.

5. Hero y canvas de Three.js

El hero había acumulado varios HUDs (estado, ubicación, coordenadas) y un badge “Based in Costa Rica” en la tarjeta. El fondo no siempre coincidía con el modo oscuro, y el canvas de Three.js podía dar un flash o desincronizarse después de cambiar el tema.

Qué hicimos: Dejamos el hero siempre oscuro (mismo slate en modo claro, coincide con el fondo del sitio en modo oscuro). Redujimos el HUD a un solo bloque: bandera de Costa Rica más “Hecho con ♥ en Costa Rica” (totalmente localizado). Quitamos el badge extra de la tarjeta y subimos la pastilla de scroll y la hicimos un poco más ancha. Para el canvas de Three.js usamos un color de limpieza oscuro para que no haya flash de luz al cargar. Aumentamos onda y turbulencia, añadimos un flujo de color verde, activamos antialias y mayor resolución de grid, y diferimos el init un frame para que el canvas reinicie limpio tras un cambio de tema. Los wrappers de gradiente ahora escuchan nuestro evento de tema aplicado y solo se actualizan cuando cambia realmente el modo oscuro, así que el hero y el resto del sitio siguen en sync en todos los idiomas, incluido español.

Por qué importa: Un hero claro, sin ruido visual, y un canvas que se comporta igual en ambos temas y en toda la navegación del cliente.

6. El carrusel de proyectos

Queríamos que la sección de enfoque mostrara nuestro trabajo sin mandar a la gente de cacería. La página de proyectos ya tenía un modal que se abre para un proyecto dado; necesitábamos una forma de mostrarlo en la homepage.

Qué hicimos: Añadimos un carrusel horizontal de proyectos en la sección de enfoque. Usa los mismos datos de proyectos que el resto del sitio. Cada tarjeta enlaza a /{lang}/projects#project-{key} así que al hacer clic en “Ver proyecto” llegas a la página de proyectos con el modal correcto ya abierto. Le pusimos botones prev/siguiente con nuestro icono de flecha estándar, scrollbar con estilo y auto-scroll (intervalo de 5 segundos) que se pausa al hacer hover y cuando el carrusel está fuera de vista. En desktop añadimos margen inferior para que la sección respire. El carrusel usa el mismo lenguaje de diseño que el resto del sitio: sin hover en las tarjetas, solo en los botones y enlaces dentro.

Por qué importa: Quien visita ve nuestro trabajo en contexto sin salir de la homepage, y el flujo enlace-modal funciona en ambos idiomas.

7. Documentación viva

Dejamos atrás archivos markdown sueltos en la raíz. Todo vive ahora en el directorio /documentation:

• Design.md: Cada regla sobre bordes (1px), redondeos (rounded-md), botones, iconos y hover queda registrada. Cuando dimos con un problema recurrente (como el hover jank), lo anotamos para no repetir el mismo error.
• Changelog.md: Historial de versiones y notas de release. La fuente de verdad de qué se envió y cuándo.
• About.md: Resumen de funcionalidades y del sistema; enlaces al resto de la documentación.
• Marketing.md: Voz, ethos y notas de SEO para que la copy siga alineada con cómo queremos sonar.
• Release.md: Cómo subimos versiones, actualizamos el changelog y etiquetamos releases.
• Debt.md: Somos honestos con lo que sigue roto y quién se hace cargo.
• Auditorías fechadas: Guardamos auditorías de UX y rendimiento con fecha en /documentation/dated/ para seguir nuestro avance en el tiempo.

La raíz se queda mínima: README (qué es el proyecto, cómo ejecutarlo, enlaces a docs) y nuestro archivo de flujo. Un solo lugar donde mirar, la misma estructura en todos nuestros proyectos.

8. Alineación de la página de proyectos

La página de proyectos (grid del portafolio, modal de foco, búsqueda y filtros) se alineó con los mismos estándares que aplicamos en todo el sitio.

Qué hicimos: Cada control interactivo sigue ahora el sistema de diseño. El botón “Ver proyecto” en cada tarjeta tiene icono de flecha (ButtonIcon) y el mismo hover que ButtonMain (translate-y-1, sombra). El botón de cerrar del modal usa ButtonIcon (close) y un borde claro para que se lea como control. El enlace “Visitar sitio en vivo” en el modal es un CTA correcto: borde de 1px (no 2px), icono de flecha y el mismo hover de presión. Búsqueda y orden usan rounded-md y bordes con tokens de diseño; los pills de filtro usan border-accent/30 y un estado activo con scope (borde y tinte accent) para que el filtro seleccionado sea obvio sin estilos a medida. Las zonas de imagen de las tarjetas usan rounded-t-lg en lugar de un radio más fuerte para que las tarjetas sigan consistentes con el resto del sitio.

Por qué importa: La página de proyectos es a donde enviamos a la gente desde el carrusel de la homepage. Ahora usa el mismo lenguaje que el resto del sitio: un sistema de bordes y redondeos, iconos en cada botón y enlace, y sin hover con scale en elementos interactivos.

Hero y sección: El hero de proyectos se alineó con los mismos estándares que el hero de home: fondo siempre oscuro, un solo HUD arriba a la izquierda, borde de 1px en el panel de contenido y scroll pill con rounded-md y feedback por opacidad (sin scale). La sección de proyectos tiene bg-background y un overlay de gradiente radial sutil para que toda la página se sienta como un solo flujo. El panel del modal de foco usa rounded-md y border-accent/20.

9. Ampliación del FAQ y claridad técnica

Reescribimos el FAQ para que refleje lo que hacemos y cómo trabajamos. Cada respuesta se amplió usando la misma voz y datos que el resto del sitio (About, Development, servicios, hero). Dejamos explícitas las tecnologías clave: Astro, React, Tailwind, Laravel, Docker, Coolify, PostgreSQL, WordPress, Shopify y cómo las usamos. Añadimos una entrada dedicada «¿Qué tecnologías y herramientas utilizan?» y corregimos la respuesta de hosting para que no cite planes indefinidos: en su lugar describimos cómo elegimos hosting (tráfico, tipo de app, presupuesto) y que desplegamos con Docker y Coolify. El hero y el layout de la sección del FAQ se alinearon con el patrón de páginas internas (tarjeta centrada, gradiente, grid blueprint, scroll pill) y el acordeón usa los mismos design tokens y estilo de tarjeta que el resto del sitio. EN y ES están totalmente alineados.

---

Dónde estamos (cabos sueltos y todo)

¿Está el sitio perfecto? No. Todavía hay cabos sueltos. Hay inconsistencias a las que no hemos llegado, y Debt.md sigue teniendo entradas que nos quitan el sueño. Pero de eso se trata. Este post no es una bandera de “misión cumplida”; es un reporte de avance.

Hemos puesto la base:

• Nuevo logo e identidad visual: El logo de Vector Costa Rica 2026 está en vivo en todo el sitio. Cambia correctamente en modo oscuro y en todos los idiomas (incluido español). Una marca, un estándar.
• Hero y Three.js: Hero siempre oscuro, un solo HUD (“Hecho con ♥ en Costa Rica”), sin flash. El canvas se mantiene en sync con tema e idioma en todos los locales.
• Carrusel de proyectos: Scroll horizontal de tarjetas de proyectos en la sección de enfoque de la homepage; los enlaces “Ver proyecto” abren el modal correcto en la página de proyectos vía hash en la URL. Auto-scroll, scrollbar con estilo, mismo lenguaje de diseño.
• Página de proyectos: Grid, modal, búsqueda y filtros alineados con los estándares de diseño. ButtonIcon en Ver, Cerrar y enlace Live; rounded-md y bordes de 1px; pills de filtro con tokens accent y estado activo con scope.
• Tarjetas Why Us: Seis tarjetas con iconos e i18n completo en la sección de enfoque para que la propuesta de valor sea clara en ambos idiomas.
• Modo oscuro y sync de tema: Variante dark de Tailwind por clase; el logo del navbar cambia correctamente en todos los locales. Tema e idioma se mantienen en sync tras la navegación del cliente.
• Integración de Orion: Nuestro CRM/Facturación está en vivo, allanando el camino para una nueva experiencia de cliente.
• Tailwind 4+: Adoptamos por completo el enfoque CSS-first. Sin proliferación de archivos de config; tokens y reglas de diseño viven donde podemos encontrarlos.
• Rigor de flujo: Seguimos un modelo de ramas estricto (feature → dev → production) con releases etiquetados y despliegues automatizados vía Coolify. Sin commits directos a production; código y seguimiento de tareas se mantienen alineados.
• FAQ: Contenido ampliado (EN/ES) y alineado con el posicionamiento del sitio y las tecnologías clave. Nueva entrada «¿Qué tecnologías y herramientas utilizan?»; respuesta de hosting aclarada; hero y sección usan el mismo lenguaje de diseño que el resto de páginas internas.

Arreglamos lo que estaba roto, anotamos nuestras decisiones e hicimos que las herramientas respalden la forma en que realmente trabajamos. Ese es el enfoque que usamos con nuestros clientes, y por fin es el que usamos para nosotros mismos.

Gracias por seguir ahí. Recién estamos arrancando.