Globaly | Caso de estudio

Rol: Full-stack Engineer
Tipo de trabajo: Colaboración con equipo
Industria: Colaboración inmersiva • SaaS de espacios de trabajo virtuales

Resumen

La home ahora es un sitio web 3D inmersivo: el visitante recorre una oficina virtual renderizada en tiempo real con Three.js — luz horneada en Blender, avatares que llegan, se saludan y conversan con audio espacial opcional, una cámara guiada por el scroll y, en el celular, el espacio se explora con el dedo o inclinando el teléfono. La calidad se adapta a la GPU de cada dispositivo para que corra fluido en cualquier notebook. Globaly es el sitio público de una plataforma de colaboración inmersiva — espacios digitales donde equipos distribuidos trabajan, entrenan y presentan juntos sin estar en el mismo lugar. El sitio no es el producto: es la capa comercial, editorial y de descubrimiento que lo rodea. Un visitante recorre 33 páginas: la plataforma y su compatibilidad de dispositivos, siete páginas de soluciones, tres páginas por segmento de empresa, un hub de enterprise con trust center y residencia de datos, una tabla de precios de cinco planes que se renderiza en USD o EUR según el país del visitante, cuatro páginas comparativas, y un blog con búsqueda, filtro por categoría y paginación alimentado desde un CMS headless compartido. Todo el contenido está traducido a inglés, francés y español, con el idioma negociado por cookie en lugar de por prefijo de URL. La colaboración está documentada dentro del propio código: los comentarios citan los documentos de estrategia del cliente por sección como justificación de las decisiones de arquitectura de información, y el repositorio incluye un sistema SEO de tres documentos con reglas explícitas anti-alucinación.

El desafío

Un producto de colaboración inmersiva compite contra categorías que el comprador ya conoce y contra una objeción implícita: "ya tengo videollamadas". El problema real no era tener un sitio, sino tener uno que pudiera sostener una tesis de posicionamiento página por página, en varios idiomas, para varios segmentos, y que además fuera encontrable — no sólo por buscadores, sino por los motores de respuesta que hoy median parte de la investigación B2B. El precio se define una sola vez en USD y se convierte y formatea en el render, de modo que los datos estructurados y la tabla visible leen la misma constante y no pueden desincronizarse. La moneda se decide por un país resuelto en middleware desde cualquiera de cuatro headers de geolocalización posibles, normalizados a un header interno que se borra antes de escribirse para que un cliente no pueda falsear su país. La capa de i18n sirve los tres idiomas desde la misma URL con un deep merge sobre el catálogo inglés, así una página sin traducir cae a inglés legible en vez de imprimir la ruta de la clave. Se construyó a medida en vez de usar un builder porque la mitad del valor está en cosas que esas herramientas no dan: precios sensibles a geolocalización resueltos en el servidor, un catálogo de 1.689 claves con fallback jerárquico, datos estructurados derivados de las mismas constantes que la UI, y headers de seguridad razonados uno por uno.

Enlaces

Repositorio de GitHub

Privado — proyecto de cliente

Arquitectura del sistema

Una aplicación en Next.js 16 App Router renderizada íntegramente en el servidor, sin base de datos propia. La decisión central fue mantener el contenido estructural en el repositorio —en catálogos i18n tipados y constantes de TypeScript— y reservar el CMS headless exclusivamente para el contenido editorial de alta frecuencia. Eso permite componer 33 páginas a partir de un puñado de componentes de sección parametrizados por namespace de traducción, y que la navegación, los precios, la matriz comparativa y el JSON-LD se deriven todos de una única fuente en código, versionada y revisable en un pull request.

Arquitectura de la aplicación

Next.js 16 App Router con React Server Components; los componentes cliente se limitan a la interacción concreta: menús, cambio de tema, formularios y observers de scroll.
Un segmento de locale con middleware que resuelve el idioma por cookie, sin prefijo en la URL.
Páginas de sección construidas como componentes reutilizables parametrizados por namespace, de modo que una nueva página de solución es un archivo de unas 20 líneas más un bloque de traducciones.
Rutas dinámicas con params estáticos para las páginas comparativas; el detalle de artículo se renderiza dinámicamente porque depende del CMS en vivo.
Alrededor de 13.200 líneas de TypeScript repartidas en 53 componentes y 33 páginas.

Funcionalidades de la plataforma

Cinco planes de precios con la moneda resuelta por geolocalización en el servidor y formateada según el locale.
Blog con búsqueda, filtro por categoría, paginación y carga incremental, servido a través de un proxy de API interno sobre el CMS.
Cuatro páginas comparativas generadas a partir de un catálogo tipado que lleva un sello de verificación de datos.
Formularios de contacto y newsletter validados con Zod y despachados por Postmark con doble envío: confirmación al usuario más notificación interna.
Tema claro y oscuro sin parpadeo, un overlay de intro coreografiado y renderizado en el servidor, un indicador de progreso entre rutas y soporte de reduced-motion respetado en 19 bloques de estilos distintos.

Modelo de datos

Sin base de datos propia: el modelo de datos es el contrato con el CMS, tipado en un módulo dedicado.
Una forma cruda de artículo del CMS que incluye autor, categoría, tags, campos SEO, localizaciones y programación de publicación, mapeada mediante una función explícita a un tipo de post propio de la aplicación.
Multi-tenant del lado del CMS: la instancia se comparte entre proyectos del estudio y cada consulta filtra por slug de proyecto. El sitio es un tenant, no el dueño del CMS.
Separación por entorno: en producción se leen los artículos publicados y fuera de ella los borradores, según el flag de entorno.

Autenticación

El sitio no autentica usuarios: el login es un link saliente al dominio del producto y el call to action principal abre una sala de demo sin ningún formulario de registro delante. La única credencial del sistema es el token de servicio del CMS, y es opcional por diseño.

Sin auth propia
Login externo
Demo sin registro
Token de CMS opcional
Sin sesiones
Sin roles

Infraestructura y deploy

Desplegado en el VPS propio del estudio por SSH detrás de Cloudflare, en lugar de una plataforma gestionada; una decisión que condiciona código real, ya que el middleware lee cuatro posibles headers de geolocalización justamente porque no puede asumir los de un único proveedor.

Contenedores y build

Dockerfile multi-stage sobre node:21-alpine con targets de desarrollo y producción, seleccionados según el entorno en compose.
Healthcheck cada 30 segundos con un período de gracia inicial.
Variables de entorno públicas declaradas como build args, porque el framework las incrusta en tiempo de build en lugar de leerlas en runtime.
El build de producción corre sin caché de forma deliberada.

CI/CD

Bitbucket Pipelines con cuatro entornos de despliegue apuntando a tres hosts distintos: producción, producción alpha y dos ramas de staging.
Cada step envía por SSH un script de deploy a la cuenta de deployer correspondiente.
Sin credenciales en el repositorio: el script de deploy recibe sus argumentos desde las variables de despliegue y escribe el archivo de entorno en el servidor en cada deploy, eliminando el anterior.
El measurement ID de analytics se configura sólo en producción, así que staging se despliega con un valor vacío y el componente de analytics no renderiza nada en lugar de medir contra la propiedad real.

Host y entrega

Los despliegues fuera de producción apuntan automáticamente al widget de chat de desarrollo, derivado del flag de entorno en lugar de sumar otro argumento al pipeline.
El script de deploy limpia volúmenes, imágenes y caché del builder antes de cada build, crea directorios y corrige permisos de forma idempotente, y hace un hard reset del checkout para que sea determinístico.
Media del hero servida como immutable con URLs versionadas; los assets generales tienen un día de frescura más una semana de stale-while-revalidate, para que un reemplazo con el mismo nombre se propague solo.
URLs legacy redirigidas de forma permanente a la arquitectura de información aprobada.

Construido con

TypeScript

Next.js

React

Three.js (WebGL)

Blender (modeling & light baking)

GSAP

Web Audio API (spatial audio)

Tailwind CSS

next-intl 4

Strapi

Axios

Zod 4

Postmark

React

next/font

Google Analytics 4

Docker

Bitbucket Pipelines

Cloudflare

ESLint 9

Un sitio de marketing y contenido completo en tres idiomas, entregado con su infraestructura de despliegue, su capa de datos estructurados y su sistema de contenido editorial conectado.

Superficies de la aplicación

33 páginas: home; plataforma y compatibilidad de dispositivos; siete páginas de soluciones; tres páginas por segmento de empresa; enterprise, trust centre y residencia de datos; integraciones; precios; un hub comparativo con cuatro páginas de competidores; un hub de recursos con detalle de artículo; guías, un hub de ROI con dos calculadoras de casos y una guía de proof-of-value; investigación; nosotros; contacto; video; privacidad y términos.
Navegación con menús agrupados, overflow responsive, menú mobile, selector de idioma en navbar y footer, navegación por secciones con scroll-spy, cambio de tema, volver arriba y progreso entre rutas.
Un design system en Tailwind v4 con tokens de tema claro y oscuro, cuatro familias tipográficas self-hosted y alrededor de 1.970 líneas de CSS de animación y layout con soporte de reduced-motion.

Integraciones

CMS headless con un proxy de API interno, mapeo tipado y degradación elegante a un estado vacío.
Email transaccional con Postmark y un modo mock explícito cuando falta el token, que loguea en lugar de romper en entornos locales y de preview.
Analytics montado de forma condicional y un widget de chat de terceros en Shadow DOM con host configurable por entorno.

Documentación y herramientas internas

Un sistema de tres documentos de SEO, answer-engine y generative-engine que cubre doctrina, aplicación y proceso, más una biblioteca de prompts, un reporte de aplicación y una auditoría de schema.
Reglas explícitas contra alucinaciones y un esquema de etiquetado de evidencia que distingue afirmaciones observadas, inferidas, supuestas y recomendadas.
Material de dirección de arte, incluidos los originales de las placas del hero y candidatos de layout.
El propio código funciona como documentación de decisiones: los comentarios citan las secciones del brief del cliente que justifican cada decisión de arquitectura de información, copy y call to action.