Un producto ligero que no sacrifica ni diseño ni arquitectura.
Linkims. Plataforma de link-in-bio para los artistas de Lemonims. En producción desde el primer artista, con 0 dependencias de producción y un bundle total de 18,2 KB.
Un Linktree no representa a un sello discográfico
Lemonims necesitaba un hub centralizado donde cada artista tuviera un perfil con enlaces a sus plataformas: Spotify, YouTube, Instagram. Las soluciones existentes como Linktree se quedaban cortas en lo único que importaba aquí: cero control de marca, cero identidad visual por artista, y el branding de un tercero encima de un producto que representa a un sello.
La restricción no era técnica, era de producto: cada perfil tiene que sentirse una extensión de la marca del artista, no una plantilla genérica con los colores cambiados. Eso descartaba de entrada cualquier solución basada en temas predefinidos o configuración superficial.
Hoy el hub aloja tres perfiles en producción (el propio, Marces y Blanca Ferrer), con Blanca Ferrer funcionando como caso límite: tipografía serif propia (Prociono), pesos distintos, padding de CTA distinto. Todo resuelto sin tocar el CSS de los componentes.
La decisión que define todo lo demás: nada de framework
Antes de cualquier componente o token, la primera decisión fue de arquitectura: TypeScript vanilla, sin framework.
Por qué.
El producto no tiene estado, ni reactividad, ni composición a escala. Son páginas estáticas renderizadas desde JSON. Meter un framework habría añadido unos 40 KB de runtime para resolver algo que document.createElement cubre en 227 líneas. El resultado es un proyecto con cero dependencias de producción, solo 4 devDependencies para build.
Tokens que se adaptan solos.
Espaciado (base 4px), tipografía, radios, motion y blur están definidos como custom properties en :root. Los tokens cambian en los breakpoints, y los componentes que los consumen se adaptan sin CSS adicional. El token es el contrato entre diseño y componente: no una referencia, una fuente única de verdad.
Un tema por artista, sin tocar componentes.
Cada artista (.theme--marces, .theme--arodav, .theme--blanca-ferrer) sobreescribe un set de custom properties: paleta, gradiente, tipografía, efectos de cristal. Añadir la identidad visual completa de un artista nuevo son 6 custom properties, no una reescritura de componente.
El layout también es dato, no código.
Grid CSS de 6×5. Cada tarjeta define su posición (row, col, rowSpan, colSpan) directamente en el JSON del perfil, y TypeScript inyecta esas coordenadas como custom properties. Añadir un artista nuevo es un JSON y un HTML, no una sesión de desarrollo.
Multi-página real, no un SPA disfrazado.
Cuatro entry points en Vite. Cada artista tiene su propio index.html con <title>, meta tags y favicon dedicados. URLs limpias (/arodav/), SEO nativo, sin lógica de routing que mantener.
Los detalles que no salen en un diff
Un producto en producción para clientes reales se nota en lo que no se ve a primera vista:
- Doble requestAnimationFrame en las animaciones de entrada, para garantizar que el navegador pinta el estado inicial antes de disparar la transición.
- Favicon animado con la Page Visibility API: alterna colores cada 2s cuando la pestaña está oculta, y limpia el intervalo al volver.
- Iconos vía mask de CSS + currentColor: heredan el color del tema automáticamente, sin SVG inline que mantener por artista.
- prefers-reduced-motion respetado en todas las animaciones.
- Progressive enhancement: el HTML semántico funciona sin JavaScript, con skip link, <nav>, ARIA labels y lang="es".
Nada de esto era parte del encargo. Es lo que separa un link-in-bio hecho para un artista de una plantilla genérica con el logo cambiado.
Impacto cuantificable
18,2 KB
bundle total minificado, sin ninguna dependencia de producción
3
identidades de marca en producción sobre un único sistema de componentes
6
custom properties necesarias para dar de alta la identidad visual completa de un artista nuevo
14
atributos ARIA y skip links, accesibilidad resuelta desde la base
Lo que esto desbloquea
Añadir un artista nuevo a Lemonims ya no es un proyecto: es un JSON de perfil y un index.html. El sistema de tokens absorbe la identidad visual sin tocar un componente, y los casos límite (como Blanca Ferrer) se resuelven con custom properties, no con forks de CSS.
Esta primera versión es deliberadamente un MVP: la arquitectura de tokens ya prueba que un tema completo se reduce a un puñado de variables, pero ese ajuste todavía lo hago yo, a mano, por cada artista. El siguiente paso no es optimizar ese proceso, es eliminarlo como cuello de botella: convertir el mismo sistema de tokens en un producto configurable, con un panel donde cada artista pueda ajustar su propio diseño dentro de un sistema con límites pensados, no un editor libre que rompa la coherencia visual.
Es la diferencia entre una herramienta interna para Lemonims y un producto que cualquier artista independiente pueda usar para tener una presencia online con una identidad propia, no una plantilla más. La base técnica (tokens como contrato, temas como datos, cero dependencias) ya está puesta para soportar ese salto sin reescribirse.