Empezar un proyecto
Caso de estudio / 01

Domusa Teknik 40 MLK

Nueve cumbres, 65 kilómetros y 4.000 metros positivos en el valle del Urola, en un solo día. La web de la carrera pesaba 1,35 MB de HTML antes de cargar una foto y repartía la información en PDFs. ZubiLabs la auditó, propuso un plan en tres fases y llevó a la reunión un prototipo funcionando. Hoy es la web de la carrera, con panel de gestión incluido.

  • Proyecto para cliente
  • 2026
  • Web
  • Rol: todo
  • Estado: publicada en domusateknik40mlk.com
Domusa Teknik 40 MLK: la portada en castellano, con la cuenta atrás hasta la salida
01
Domusa Teknik 40 MLK: el perfil de altimetría de la 40 MLK, con las cimas y las barreras horarias en naranja
02
Domusa Teknik 40 MLK: el mapa interactivo del recorrido sobre la ortofoto del IGN, con las cimas y los avituallamientos
03
01 — ContextoCliente

La Domusa Teknik 40 MLK es una carrera de montaña que organiza Lagun Onak MB desde Azpeitia: la 40 MLK, de 65 kilómetros, y la 15 MLK, de 26, por las cimas de Azpeitia, Errezil, Bidania-Goiatz y Beizama. La sexta edición sale el 8 de mayo de 2027, con plazas para 550 corredores en la larga y 400 en la corta.

Su web es un WordPress con el tema Avada, dos maquetadores a la vez (Elementor y Fusion Builder), WPML y un plugin de Instagram. Funciona, pero la organización la mantiene a mano, la información clave vive en PDFs y los resultados están repartidos en cuatro sitios distintos.

02 — ProblemaCliente

La portada envía 1,35 MB de HTML antes de cualquier imagen, porque el tema inyecta todo su CSS en cada página. En el monte, con poca cobertura, es justo cuando un corredor necesita la ficha técnica. Y esa ficha, con avituallamientos, desniveles y barreras horarias, estaba en tablas y PDFs que obligan a hacer zoom en el móvil.

Hay enlaces rotos, rutas con un prefijo erróneo y la guía del espectador solo existe en euskera. La misma fecha de la carrera se edita a mano en varios sitios y ya no coincide entre la portada y las fichas. La organización necesitaba publicar noticias, patrocinadores y avisos sin depender de nadie, y sin perder lo que hoy editan desde WordPress.

03 — SoluciónCliente

Una web nueva con los colores sacados del degradado del logo y una tipografía condensada y deportiva: portada con cuenta atrás hasta la salida, ficha de cada carrera con el perfil de altimetría, los avituallamientos y sus barreras horarias, clasificaciones por edición, galería, patrocinadores por niveles, noticias y contacto. Cada ficha suma un mapa del recorrido sobre la ortofoto del IGN que se puede sobrevolar entero. Euskera como idioma principal, castellano e inglés, cada uno con sus URLs.

La organización edita todo en /admin, un panel hecho con Payload dentro de la misma app: noticias con borrador, publicación programada e historial de versiones, carreras, patrocinadores que se ordenan arrastrando, galería, datos de la edición, mensajes del formulario y usuarios. Cada campo tiene su versión en cada idioma en la misma pantalla, con vista previa en vivo. Un aviso urgente aparece en todas las páginas con un clic.

04 — Rol

Todo. La auditoría de la web actual, el documento de propuesta con 25 mejoras en tres fases, el diseño a partir del logo, la migración de los textos, fichas técnicas, noticias y fotos, la app Next.js, el panel de gestión, la infraestructura en Vercel con Turso y Vercel Blob, la presentación a la organización y la puesta en producción.

05 — ArquitecturaIngeniería
BROWSEREU · ES · ENNEXT.JS 16Static · VercelPAYLOAD · /ADMINSame appURGENT ALERT BARSVG PROFILESAVE · REVALIDATELIVE PREVIEWOG · SITEMAPTURSO · BLOB

Decisiones clave, y por qué:

  • El panel vive dentro de la web. Payload corre en la misma app Next.js, así que no hay un CMS aparte que alojar, pagar o actualizar. La web lee el contenido a través de una sola capa que devuelve los mismos tipos que antes salían de archivos estáticos, y los componentes apenas cambiaron al conectar el panel.
  • Estático, y se regenera al guardar. Todas las páginas públicas se prerenderizan en el build. Al guardar en el panel, un hook regenera las páginas afectadas y el sitemap, así que el público ve el cambio en segundos sin que la web dependa de una base de datos en cada visita.
  • Los datos dibujan la ficha. El perfil de altimetría es SVG generado a partir del GPX oficial y los avituallamientos de la ficha técnica, sin librería de gráficos y sin JavaScript en el cliente. Las barreras horarias van en naranja, el único color fuera del azul de la marca, porque es la información que no se puede pasar por alto.
  • SQLite en local, Turso en producción. En desarrollo la base de datos es un archivo y las fotos van a una carpeta. En Vercel el disco es efímero, así que los datos van a Turso, que es SQLite alojado con el mismo adaptador, y las fotos a Vercel Blob con el token OIDC del proyecto, sin claves que guardar.
06 — Tecnología
WebNext.js 16 · App Router · React 19 · TypeScript · Tailwind CSS 4
PanelPayload 3 · Lexical · Live Preview · Versiones y borradores
DatosSQLite · Turso · Migraciones de Payload
MediosVercel Blob · sharp
MapaMapLibre GL · IGN: PNOA y MTN · MDT de 5 m
IdiomasEU · ES · EN · hreflang · Localización por campo
SEOImágenes next/og · Open Graph · JSON-LD · Sitemap
OpsVercel · OIDC
07 — RetosIngeniería
  • Una carga inicial sin perder nada. El contenido migrado de la web actual se carga en el panel con una migración que se ejecuta una sola vez en el despliegue. La primera vez corrió sin Vercel Blob conectado y las fotos se escribieron en el disco efímero del build: los registros quedaron apuntando a archivos que no existían. Una segunda migración las vuelve a subir sobre los mismos registros, sin romper la galería, las noticias ni las carreras que las usan.
  • Un perfil honesto, primero sin el GPX. Mientras no hubo track oficial, el perfil se construyó con las altitudes oficiales de avituallamientos y cimas, interpolando el punto kilométrico de cada cima entre controles. Con el GPX, el perfil y el mapa salen del track, las altitudes del modelo digital del terreno de 5 m del IGN y las cimas conservan su altitud oficial. La web lo explica debajo del gráfico.
  • El contenido nunca depende del JavaScript. Las animaciones de entrada usan timelines de scroll de CSS dentro de un @supports y el texto parte siempre visible. Solo son componentes de cliente el menú móvil, la cuenta atrás y el mapa: si algo del JavaScript falla, la web se sigue leyendo entera, y se respeta la preferencia de reducir el movimiento.
08 — Resultado

La web está publicada en domusateknik40mlk.com, en euskera, castellano e inglés: las dos carreras con su ficha, perfil y mapa del recorrido, las clasificaciones de todas las ediciones desde 2022 con buscador por nombre, dorsal o población, la guía del espectador en los tres idiomas, galería, patrocinadores, noticias y contacto. La portada pasa de 1,35 MB de HTML a menos de 200 KB.

La propuesta se presentó a la organización en octubre de 2026 y la web se publicó ese mismo mes, con las direcciones de la web anterior llevando a las nuevas. Desde entonces la organización publica noticias, avisos y patrocinadores desde el panel, de cara a la sexta edición del 8 de mayo de 2027.

09 — Aprendizajes
  • Llevar algo que funcione. Un prototipo con su contenido real convence más que cualquier maqueta. La organización no tiene que imaginar el panel: entra, cambia un texto y lo ve en la web.
  • Medir antes de opinar. Decir que una web es lenta no mueve a nadie; 1,35 MB de HTML antes de la primera foto, sí. El diagnóstico se escribió con cifras y sin criticar el trabajo hecho.
  • Un dato, un sitio. La fecha de la carrera no coincidía entre la portada y las fichas porque se editaba a mano en varios sitios. En el panel se escribe una vez y alimenta la cuenta atrás, las fichas y las imágenes para compartir.