Vector Solutions - Pionero en Tecnología de Telecomunicaciones

#Visión general del proyecto

Vector Solutions forma parte del grupo VECTOR de Gdynia, con sede en la calle Krzemowa 6, un grupo que opera desde 1988 y que empezó fabricando amplificadores para instalaciones de televisión por cable. En 2001 la empresa desplegó DOCSIS en las redes de cable polacas, desde 2007 desarrolla sistemas telemétricos y hoy reúne a más de doscientos ingenieros de software, sistemas y hardware. Sus clientes son operadores de cable, compañías de telecomunicaciones y radiodifusores de televisión, es decir, compradores que leen una ficha técnica antes de mirar una página de inicio.

El proyecto llegó a nosotros en 2017, el mismo año en que el grupo abrió el proceso de rebranding que cerró en 2019 con la creación de VECTOR BLUE HUB. La implementación duró alrededor de seis semanas. El layout y la colocación de los elementos los aportó el cliente; nuestra parte fueron las plantillas, el comportamiento responsive, el modelo de contenido, las integraciones y el trabajo de rendimiento.

#Contexto del cliente

#Liderazgo en el sector

La posición de Vector Solutions no se apoya en una campaña de marca sino en una trayectoria larga en un sector donde el producto se compra por especificación. El grupo opera en Polonia y en el resto de Europa, conoce por dentro las industrias del cable, las telecomunicaciones y los medios, y mantiene relaciones de largo recorrido con operadores que integran su equipamiento en redes que llevan años funcionando. Su catálogo cubre tecnologías de comunicación e infraestructura de varias generaciones a la vez, y esa continuidad es justamente lo que complica el trabajo web: un fabricante joven describe cinco productos, uno con treinta años de historia describe familias enteras de equipos que conviven en el mercado en distintos estados de ciclo de vida.

#Qué implicaba eso para el sitio

La misión declarada del grupo, apoyar la evolución de la infraestructura digital de sus clientes, se traduce en una exigencia concreta para la web: el catálogo tiene que sostener productos de épocas tecnológicas distintas, algunos todavía mantenidos en redes de operador y otros en retirada, y la documentación de unos y otros tiene que seguir siendo accesible en paralelo. Por eso el sitio no podía ser un folleto con cinco tarjetas de servicio. Tenía que soportar un modelo en el que una solución tiene varias variantes, cada variante su propia especificación, y esa especificación a veces sólo es visible para un socio identificado.

La segunda consecuencia tiene que ver con quién lee. Un ingeniero de un operador de cable busca un parámetro concreto, no un relato sobre innovación. De ahí que la búsqueda y el filtrado por atributos técnicos pesaran más en las decisiones que la capa visual, cuyo layout además venía dado. Esa prioridad ordena todo lo demás: si lo que más se usa es encontrar una variante y comparar dos fichas, entonces el rendimiento del catálogo y la claridad de las tablas importan más que cualquier elemento decorativo de la portada.

#Implementación técnica

#Arquitectura de la plataforma

La pila es WordPress con un tema a medida, Redis para la caché de objetos, Varnish delante para la caché de páginas y Cloudflare como capa de borde. Tres niveles de caché en una sola implementación suenan a exceso hasta que se ve que cada uno atiende un tipo distinto de petición. Cloudflare entrega los ficheros estáticos y las páginas anónimas sin que la petición llegue siquiera al servidor de origen. Varnish guarda las vistas compuestas del catálogo, esas cuya generación cuesta una docena larga de consultas a la base de datos. Y Redis acorta esas mismas consultas para todo lo que sí acaba entrando en PHP, porque siempre queda una parte que no se puede servir desde una copia guardada.

La tensión arquitectónica de este proyecto está exactamente en el punto donde la caché se cruza con la personalización. El sitio tiene que distinguir si quien mira es un visitante anónimo, un socio identificado o una persona de la propia empresa, y mostrar a los tres versiones distintas de la misma dirección. La caché de borde detesta eso por definición, porque toda su ganancia viene de entregar el mismo byte a mucha gente. La resolución consistió en separar las capas: el esqueleto de la página y el catálogo son comunes y se cachean de forma agresiva, mientras que todo lo que depende del rol se pide en una petición aparte después de identificarse y nunca entra en Varnish. Dicho de otro modo, la personalización se paga solamente en las partes que de verdad cambian por usuario, y no encareciendo cada visita anónima.

Sobre esa base se construyeron tres bloques funcionales. El primero es el sistema de gestión de ofertas, que permite configurar propuestas complejas a partir de módulos, aplicar tarifas de varios niveles según el tipo de socio y generar la propuesta sin rehacerla a mano cada vez, con conexión a los sistemas de facturación para que lo acordado y lo facturado no vivan en dos sitios distintos. El segundo es la presentación del portafolio, con galería filtrable de proyectos y carga dinámica de contenidos, pensada para que un caso de éxito se pueda añadir sin tocar plantillas. El tercero es la integración de datos en tiempo real, que trae información de fuentes externas al sitio y la muestra sin obligar a nadie a actualizar una página a mano cada semana.

#Experiencia del frontend

Como el layout y la colocación de los elementos venían del cliente, nuestra parte fue traducirlos a plantillas, a un comportamiento responsive coherente y a un modelo de contenido que se pueda mantener después del lanzamiento. La estética no fue objeto de discusión; el orden de la información sí lo fue, porque es donde se decide cuántos clics separan a un ingeniero del dato que ha venido a buscar.

La interfaz adapta lo que muestra al perfil del usuario, permite filtrar soluciones por varios ejes a la vez y compararlas una al lado de otra. El filtrado multidimensional es justo el punto donde un catálogo técnico suele venirse abajo: cada atributo que se añade multiplica el número de combinaciones posibles, y una implementación ingenua consulta la base de datos una vez por filtro, de modo que la página se vuelve más lenta cuanto más útil se vuelve el filtro. Aquí el conjunto de atributos se calcula una vez y se guarda en Redis, y cambiar un filtro no recarga la página entera, sólo sustituye la lista de resultados.

El layout es mobile-first y cumple WCAG 2.1, lo que en un catálogo de producto significa sobre todo dos cosas concretas. Primera, que las tablas de especificación tienen los encabezados asociados a sus celdas, porque una tabla de parámetros sin esa asociación es, para un lector de pantalla, una sucesión de cifras sin significado, y esa tabla es el contenido principal de la página. Segunda, que los filtros se pueden manejar con el teclado, ya que son el mecanismo de navegación real del sitio y dejarlos dependiendo del ratón equivale a cerrar el catálogo a parte de sus lectores.

#Sistemas de backend

La gestión de contenidos se apoya en tipos de entrada propios para soluciones y casos de éxito, y en una taxonomía pensada para que un mismo equipo pueda clasificarse por familia, por generación tecnológica y por tipo de red sin duplicar fichas. El contenido es multilingüe desde el primer día, con WPML, y pasa por un flujo de aprobación antes de publicarse, con control de versiones de los cambios: en una ficha técnica una corrección mal hecha no es una errata, es un dato equivocado que alguien puede acabar usando para dimensionar una instalación.

La gestión de usuarios distingue socios, clientes y personal interno mediante control de acceso basado en roles, sostiene el portal de socios y la administración de cuentas, y conecta el seguimiento de leads con el CRM para que una solicitud enviada desde la web aparezca en el mismo sitio donde el equipo comercial ya trabaja. Las capacidades de integración cubren esa conexión con Salesforce, la automatización de marketing con HubSpot, las pasarelas de pago y los sistemas de facturación, siempre con la misma regla: WordPress no habla con ningún sistema externo directamente, sino a través de su propio adaptador.

#Funcionalidades avanzadas

#Sistemas dinámicos de ofertas

La configuración de ofertas es modular: las soluciones se empaquetan en bloques, los niveles de precio se gestionan por tipo de socio, hay reglas de disponibilidad geográfica y la generación del documento final está automatizada. El valor de ese automatismo no es la velocidad de tecleo, sino la consistencia. Cuando una propuesta se arma a mano en un procesador de texto, cada comercial arrastra la versión que tenía guardada, y las condiciones de hace dos trimestres vuelven a salir a la calle sin que nadie lo note. Cuando se arma a partir de los mismos datos que alimentan el catálogo, una condición cambiada se cambia una vez.

Para clientes concretos existen precios acordados por socio, cálculo de descuentos por volumen, opciones de marca blanca y acceso por API para los clientes corporativos que prefieren consultar el catálogo desde sus propios sistemas en lugar de entrar al sitio. Esa última pieza suele infravalorarse: en un entorno B2B, la integración que evita que alguien copie cifras a mano entre dos pantallas elimina toda una clase de errores que después nadie sabe de dónde salieron.

#Panel de datos en tiempo real

El panel muestra datos en vivo sobre tendencias del sector, adopción tecnológica e indicadores de mercado, con vistas filtrables, comparaciones de series temporales, representación geográfica, exportación y generación programada de informes. Lo interesante no es la lista de widgets, sino cómo se sirven sin estropear la página.

La decisión de fondo es que los datos en vivo nunca bloquean el primer renderizado. La página sale completa sin ellos y el panel se carga después, a través de endpoints separados entre los críticos y los que pueden esperar. Los datos de referencia que casi no cambian se quedan del lado del navegador, de modo que una segunda visita no vuelve a preguntar al servidor lo mismo. Y la frecuencia de refresco se ajusta a la velocidad real a la que cada dato se mueve, en lugar de fijar un único intervalo para todo el panel. Esa distinción decide la factura: consultar todo cada pocos segundos queda vistoso en una demostración y genera tráfico que alguien paga durante años, sin dar al lector ni un solo dato que no fuera a tener un minuto más tarde.

#Experiencia de usuario personalizada

El motor de personalización perfila al usuario por sector, rol e intereses, sigue su comportamiento dentro del sitio y recomienda contenidos en función de ello, con paneles propios por tipo de usuario y comunicaciones dirigidas. Conviene decir con qué se paga esa comodidad: cada elemento personalizado es un elemento que no se puede servir desde la caché compartida. Por eso la personalización se concentra en zonas acotadas de la página en lugar de repartirse por toda ella, y por eso el esqueleto común se mantiene idéntico para todos. Un sitio personalizado de arriba abajo es, en términos de infraestructura, un sitio sin caché.

#Rendimiento y escalabilidad

#Optimización técnica

El trabajo de velocidad atacó cuatro frentes: renderizado en servidor para que la primera carga no dependa de ejecutar JavaScript, carga diferida del contenido por debajo del pliegue, optimización de imágenes con formatos modernos e incrustación del CSS crítico para que el navegador pueda pintar sin esperar a una hoja de estilos completa. A esos se suma el más aburrido y el más rentable en un catálogo: la revisión de las consultas a la base de datos, buscando específicamente las que crecen en proporción al tamaño del catálogo en lugar de mantenerse constantes.

La estrategia de caché es la ya descrita en varias capas, más el cacheado de fragmentos dinámicos, el de las respuestas de las API externas y las políticas de caché del navegador. La parte que más se descuida en implementaciones parecidas es la última: los procesos de invalidación. Una caché sin una regla clara de cuándo se vacía y quién la vacía acaba sirviendo precios viejos, y ese fallo es peor que la lentitud que la caché venía a resolver, porque no se nota hasta que alguien reclama.

En cuanto a la escalabilidad, el planteamiento fue reducir lo que llega al origen antes que añadir potencia. Los recursos estáticos salen de la CDN, las operaciones no críticas se sacan de la petición del usuario y se procesan en cola, y el sitio degrada de forma controlada bajo carga: si una sección depende de un sistema externo que no responde, desaparece esa sección y no la página. Añadir capacidad es la respuesta cara y además engañosa, porque un servidor más grande absorbe un pico y deja intacto el motivo por el que ese pico llegaba hasta la base de datos.

#Medidas de seguridad

La capa de seguridad combina cifrado SSL/TLS en todo el sitio, un cortafuegos de aplicación web, protección frente a ataques de denegación de servicio, detección de intrusiones y auditorías periódicas, con Wordfence como pieza de control dentro de WordPress. En la protección de datos el trabajo se centró en el cumplimiento del RGPD, el cifrado de los datos en reposo y en tránsito, el registro de accesos y unas copias de seguridad con procedimiento de restauración probado.

Hay un matiz que en este proyecto no es teórico. Parte de la documentación técnica está sujeta a acuerdos de confidencialidad con operadores, así que el control de accesos no es una comodidad de la interfaz sino una obligación contractual. Eso condiciona dónde se comprueba el permiso, algo que se explica más abajo, y también qué se registra: saber quién descargó qué especificación y cuándo es parte del cumplimiento, no una métrica de marketing.

#SEO y marketing digital

#Optimización para buscadores

En SEO técnico el sitio lleva marcado de esquema para la organización y sus servicios, mapas XML con ponderación de prioridad, una estructura de URL legible, etiquetas canónicas y una estrategia de enlazado interno que conecta cada variante con su familia de producto y con los casos de éxito donde aparece. En un catálogo de estas dimensiones el enlazado interno hace un trabajo que ninguna otra técnica sustituye: es lo que evita que una variante rara quede sin ninguna ruta de entrada salvo el buscador interno.

La estrategia de contenidos se apoyó en páginas de aterrizaje por segmento del sector, un glosario de términos tecnológicos, casos de éxito trabajados y una biblioteca de recursos. El glosario merece una mención aparte porque resuelve un problema de vocabulario: el ingeniero y el responsable de compras de un mismo operador buscan la misma cosa con palabras distintas, y sin una página que las una una de las dos consultas no encuentra nada. El SEO internacional se apoya en hreflang para las versiones lingüísticas, variantes de contenido por país y optimización para la búsqueda local en los mercados donde el grupo tiene presencia comercial.

#Analítica y métricas

La analítica no se quedó quieta desde el lanzamiento. La implementación de 2017 arrancó sobre Universal Analytics, porque Google Analytics 4 no existía todavía, y la migración llegó más tarde como parte del mantenimiento. Conviene decirlo con todas las letras, porque las descripciones de proyectos suelen presentar la pila de hoy como si fuera aquella con la que el proyecto arrancó, y entonces ya no hay forma de distinguir una decisión de diseño de un cambio que impuso un proveedor años después.

Más allá de la herramienta, la medición cubre eventos personalizados, análisis de embudo y mapeo del recorrido del usuario. En un catálogo técnico el evento más valioso no es el envío de un formulario sino la descarga de una especificación: indica qué variante retiene de verdad la atención de un ingeniero, mucho antes de que nadie escriba una consulta comercial. El panel de informes reúne el tráfico, la generación de leads, el rendimiento de los contenidos y el seguimiento de posiciones, pero su utilidad real depende de que alguien mire esa señal temprana y no sólo el recuento de formularios.

#Resultados e impacto

Esta sección solía cerrar con una fila de cifras precisas, y ninguna de ellas sobrevive a una comprobación contra nuestros propios registros. El proyecto salió en 2017 y las mediciones, si llegaron a tomarse, se fueron con un buzón de correo que ya no tenemos. Una cifra presentada como medición y luego incapaz de nombrar su fuente es peor que la ausencia de cifras, así que aquí va lo que sí se puede afirmar con honestidad.

En el plano operativo, el efecto buscado y observable es el desplazamiento de trabajo manual: las propuestas dejan de armarse a mano, las actualizaciones de datos que antes hacía una persona cada semana las trae una integración, y el portal de socios permite que parte de las consultas se resuelvan sin abrir un ticket. En el plano comercial, el sitio pasa a funcionar como una herramienta de venta y no como un folleto, porque contiene el catálogo con el que el equipo trabaja de verdad y no una versión simplificada para visitantes.

El trabajo de rendimiento apuntó a tres cosas. Al peso de la página, manteniendo las vistas del catálogo fuera de PHP gracias a la capa de Varnish. Al tiempo hasta el primer byte, acortando el trabajo de base de datos detrás de las vistas que no se pueden cachear. Y a la tasa de aciertos de caché, que en un sitio con esta forma es el número del que dependen los otros dos, porque un fallo de caché baja la petición entera hasta el origen por muy bien afinado que esté ese origen. La fiabilidad descansa en el comportamiento de repliegue que se describe más abajo, no en una cifra de disponibilidad: una caída en uno de los sistemas externos degrada una sección y no la página entera.

#Retos y soluciones

#Reto 1: requisitos de integración complejos

El problema era integrar con varios sistemas externos, CRM, facturación y bases de datos del sector, sin que el rendimiento pagara la factura.

La solución fue una capa intermedia en la que WordPress nunca habla directamente con un sistema del cliente, sino a través de su propio adaptador para cada uno. La obtención de datos es asíncrona, de modo que un CRM inalcanzable no bloquea el renderizado de la página, y las respuestas se cachean con un tiempo de vida distinto por fuente, porque una lista de precios cambia una vez por trimestre y una disponibilidad cambia en una hora.

La decisión que más pesó fue qué ocurre cuando una integración se cae. El comportamiento por defecto de la mayoría de los plugins es mostrar un error o dejar una sección vacía, lo que en un sitio comercial se lee como si estuviera roto entero. Aquí cada adaptador lleva un valor de repliegue: la última respuesta conocida desde la caché y, si tampoco la hay, una variante estática de la sección. El visitante ve entonces una página sin el panel de datos en vivo, no un mensaje de error. Una caída en un sistema externo se convierte así en un evento para el monitoreo y no en un evento para el lector.

#Reto 2: rendimiento de los datos en tiempo real

El problema era mostrar fuentes de datos en vivo sin afectar a los tiempos de carga.

La solución ya se ha esbozado al describir el panel: los datos en vivo no bloquean el primer renderizado, los endpoints se separan entre críticos y aplazables, los datos de referencia se quedan en el navegador y la frecuencia de consulta se ajusta al ritmo real de cada dato. Merece la pena insistir en por qué esto se plantea como un problema de rendimiento y no de interfaz. Un panel que consulta sin criterio no se nota el día del lanzamiento, cuando lo miran cinco personas; se nota en la factura de infraestructura del año siguiente y en el momento en que el sitio recibe tráfico de verdad, porque cada visitante con la pestaña abierta se convierte en una fuente constante de peticiones al origen.

#Reto 3: complejidad de múltiples roles de usuario

El problema era dar soporte a tipos de usuario distintos, socios, clientes, posibles clientes y personal interno, con necesidades y permisos que no se parecen.

La solución fue un control de acceso basado en roles con vistas de panel separadas para el socio, el cliente y el personal interno, y un menú que oculta lo que un rol no puede alcanzar en lugar de llevarlo a una pantalla de denegación.

La trampa en estos sistemas es siempre la misma: comprobar el permiso en la interfaz y no en los datos. Un enlace oculto en el menú no defiende de escribir la dirección a mano, y en un catálogo donde parte de la especificación está bajo acuerdo de confidencialidad eso no es cosmética. Por eso la comprobación de rol vive donde se recupera el contenido, y la capa de vista sólo refleja lo que ya se ha resuelto por debajo. El mismo mecanismo forma la clave de caché, así que un socio nunca recibe una página construida para alguien con permisos distintos. Sin esa unión entre permiso y clave de caché, un sistema de roles correcto sobre el papel entrega contenido ajeno en cuanto se le pone una caché delante.

#Reto 4: picos de tráfico en eventos de gran afluencia

El problema eran los anuncios importantes de producto, que concentran en pocas horas un tráfico muy por encima del habitual.

La solución fue servir los recursos estáticos desde la CDN, revisar las consultas a la base de datos en busca de las que crecen con el tamaño del catálogo y mover a una cola las operaciones no críticas, como el envío de notificaciones o la reconstrucción del índice de búsqueda, para que sucedan fuera de la petición del usuario.

Las pruebas de carga previas a un anuncio se hicieron sobre una copia de producción, no sobre una instalación limpia, y esa es la frase importante de esta sección. El rendimiento de WordPress con un catálogo de varios miles de variantes y una docena de integraciones no tiene nada que ver con el de una instalación recién hecha con un tema de demostración. El cuello de botella no resultó ser PHP sino la eficacia de la caché: en un lanzamiento el tráfico entra por una única dirección que nadie ha visitado antes, así que la ola entera llega al backend a la vez. Calentar la caché antes de publicar el anuncio sale más barato que contratar una capacidad que el resto del trimestre está parada.

#Soporte y evolución continuos

#Programa de mantenimiento

El cuidado técnico posterior al lanzamiento se organiza en cuatro ritmos distintos porque los riesgos que cubren tampoco se parecen. La monitorización y las alertas funcionan de forma continua, y su trabajo es avisar de lo que se rompe entre revisiones. Las actualizaciones de seguridad son regulares y frecuentes, porque en WordPress la ventana entre que se publica una vulnerabilidad y se explota masivamente se mide en días. Las revisiones de rendimiento son periódicas y sirven para detectar la degradación lenta, esa que ninguna alerta dispara: una consulta que crece con el catálogo no falla nunca, simplemente tarda cada mes un poco más. Y las pruebas de carga se hacen antes de los anuncios de producto más grandes, que es cuando el sitio recibe la clase de tráfico que la operación diaria no reproduce.

En el plano editorial, el mantenimiento incluye la incorporación de nuevos casos de éxito, las actualizaciones de la cartera de productos, la integración de noticias del sector y el seguimiento analítico. En un catálogo técnico esta parte no es cosmética: una ficha que describe una variante retirada sin decirlo genera consultas comerciales que nadie puede atender.

#Mejora continua

El desarrollo de funciones se planifica por trimestres, incorporando lo que los usuarios piden y lo que la analítica muestra, con iteraciones de optimización del rendimiento y refuerzos de seguridad. La consultoría acompaña esa planificación con análisis de tendencias tecnológicas, comparativas frente a la competencia y revisión de los puntos donde el recorrido del usuario se interrumpe. La regla que ordena esa lista es simple: antes de añadir una función nueva conviene comprobar que las existentes se usan, porque un catálogo cargado de funciones sin uso es más difícil de mantener y no más útil.

#Resumen de la pila tecnológica

#Plataforma principal

WordPress en su versión estable con un tema propio de Vector Solutions, Advanced Custom Fields Pro para los campos de las fichas técnicas, un conjunto de plugins a medida para lo que el ecosistema no cubría y WPML para el contenido multilingüe. La elección de ACF Pro no es decorativa: en un catálogo donde cada variante tiene decenas de parámetros, la diferencia entre campos estructurados y texto libre es la diferencia entre poder filtrar y no poder.

#Rendimiento y seguridad

Redis para la caché de objetos, Varnish para la de páginas, Cloudflare como capa de borde y protección, Wordfence dentro de WordPress y WP Rocket para las optimizaciones de entrega en el navegador. Las cuatro primeras piezas actúan en puntos distintos del camino de una petición, de ahí que convivan sin solaparse.

#Integraciones

Salesforce como CRM, HubSpot para la automatización de marketing, las pasarelas de pago, los sistemas de facturación y las integraciones a medida con los sistemas del cliente ya mencionados. La analítica arrancó en Universal Analytics y pasó a Google Analytics 4 más tarde, dentro del mantenimiento.

#Herramientas de desarrollo

Git para el control de versiones, Docker para reproducir el entorno en local, GitHub Actions para el flujo de integración y despliegue continuo, y un entorno de pruebas separado. Ese entorno es el que permite lo que se cuenta a continuación, porque sin una copia razonablemente fiel de producción las pruebas serían un ejercicio de fe.

#Cómo transcurrió el trabajo

El conjunto llevó alrededor de seis semanas, contando desde el análisis de alcance hasta la publicación. El layout y la colocación de los elementos vinieron del cliente, así que la etapa que en otros proyectos consume la mayor parte del calendario aquí desapareció. Ese tiempo se fue al modelo de contenido y a las integraciones, es decir, a las partes que no se ven en una maqueta y que deciden si el sitio se puede mantener después del lanzamiento.

La decisión determinante llegó en la fase de pruebas. Las rutas por las que circula el tráfico se comprobaron sobre una copia de producción y no sobre una instalación limpia con datos de demostración. Con un catálogo de este tamaño la diferencia es de fondo: una consulta que sobre veinte productos responde en unos milisegundos puede crecer en dos órdenes de magnitud sobre varios miles de variantes, y en una instalación vacía nadie llegará a verlo nunca. Lo mismo vale para la caché, cuya eficacia sólo se puede medir sobre una distribución real de puntos de entrada, porque es esa distribución, y no el número total de páginas, la que determina cuántas peticiones acaban en el origen.

Después del arranque el proyecto entró en mantenimiento: monitorización y alertas, actualizaciones de seguridad regulares, revisiones periódicas de rendimiento y pruebas de carga antes de los anuncios de producto más grandes. Esa última pieza no es una formalidad, porque son precisamente los lanzamientos los que llevan tráfico a direcciones que nadie había visitado antes, que es justo el caso en el que la caché no ayuda.

#Conclusión

El proyecto de Vector Solutions muestra cómo una implementación cuidada de WordPress puede sostener la presencia digital de una empresa tecnológica que trabaja en el sector de las telecomunicaciones europeas. Juntando la integración de datos externos, una experiencia adaptada al tipo de usuario y un trabajo de rendimiento centrado en la caché, lo que se construyó no fue un escaparate sino la herramienta con la que el equipo comercial y el de producto trabajan a diario.

El acierto del proyecto está en entender que, para una empresa tecnológica B2B, una web no es un folleto: es una pieza operativa que tiene que sostener procesos complejos, hablar con los sistemas que ya existen y seguir siendo mantenible cuando el catálogo crezca. La plataforma de Vector Solutions cumple eso y conserva la flexibilidad necesaria para evolucionar al ritmo de un sector que cambia deprisa.