Cómo está construido
Construido como un pequeño producto de datos
El contenido vive en archivos versionados con un esquema, cada build lo valida y cada cambio pasa los mismos controles antes de llegar a producción. Así funciona, y estos son sus trade-offs.
De las notas a una página publicada
Notas de origen
Cada rol parte como un documento Markdown. Una skill de Claude convierte esas notas en dos archivos JSON: un vocabulario controlado de etiquetas y las experiencias.
Contratos
Esquemas Zod definen ambos archivos y los tipos de TypeScript se infieren de ellos, así que datos, tipos y validador no pueden desalinearse.
Reglas entre archivos
Un validador revisa lo que un esquema no puede: cada etiqueta existe en el tipo correcto, los ids son únicos y las listas del código (alias de búsqueda, etiquetas iniciales, carriles de la línea de tiempo) apuntan a datos reales.
Build estático
Si el contenido no es válido, el build falla con una lista legible de problemas. Si es válido, se convierte en HTML en inglés y español, con enlaces canónicos, hreflang, sitemap e imágenes para compartir.
Publicar y medir
El sitio corre como archivos estáticos en Render detrás de Cloudflare, sin servidor ni base de datos. Umami registra un conjunto pequeño de eventos tipados, como por qué habilidades filtran los visitantes.
Lo que cada cambio debe pasar
Lint y tipos
ESLint y TypeScript estricto, incluidas las claves de traducción tipadas, así que una traducción faltante es un error de compilación.
Validación de contenido
Los esquemas y las reglas entre archivos, ejecutados por separado antes del build.
Pruebas unitarias
Cálculo de fechas, años de experiencia con períodos superpuestos fusionados, orden, puntaje de roles relacionados, alias de búsqueda y tolerancia a errores de tipeo, y pruebas que rompen los datos a propósito para demostrar que el validador lo detecta.
Pruebas end-to-end
Cada página en ambos idiomas responde 200 con el idioma, el enlace canónico y el hreflang correctos, y se hidrata sin errores, con y sin movimiento reducido.
Accesibilidad
Chequeos automáticos de contraste en tema oscuro y claro en cada página. Su primera ejecución encontró fallas reales; los tokens de color ahora se calculan para superar 4,6:1 en cada superficie.
Presupuesto de Lighthouse
Si accesibilidad y SEO bajan de 95 o buenas prácticas de 90, el build falla; el rendimiento se sigue como advertencia.
Decisiones y sus trade-offs
1. Export estático, sin servidor
El contenido cambia cuando yo lo edito, así que cada página se prerenderiza y se sirve como archivo.
Trade-off: no hay lógica por solicitud; lo dinámico ocurre en el build o en el navegador.
2. Una capa de i18n propia y pequeña
El inglés queda en /story y el español en /es/story. La librería habitual lo resuelve con middleware, que un sitio estático no puede ejecutar, así que el traductor y los helpers de rutas son unas 200 líneas de código tipado.
Trade-off: no hay reglas de plural, y por ahora las páginas en español reciben su atributo de idioma desde un script previo al render.
3. Archivos con contratos, no un CMS
Dos archivos JSON en git son todo el modelo de contenido: se pueden comparar, revisar y validar en cada build.
Trade-off: editar requiere un pull request, y el paso de JSON crudo a datos tipados es una suposición documentada respaldada por la validación.
4. Servidor por defecto
Las páginas se renderizan en el servidor; solo la búsqueda, la grilla y el panel corren en el navegador. Lo que depende de la fecha de hoy se renderiza en el build, así el HTML y la página hidratada no pueden diferir.
Trade-off: la parte interactiva todavía recibe más datos de los que muestra. Reducir eso es el siguiente paso.
5. CV a pedido
No hay PDF para descargar. El sitio entrega lo que necesita una primera revisión, y el CV llega por correo, adaptado al rol.
Trade-off: un paso más para quien recluta, a cambio de una conversación.
6. La accesibilidad se prueba
El contraste se mide, el texto nunca baja de 12px, las zonas táctiles miden al menos 24px y el movimiento respeta la preferencia de movimiento reducido.
Trade-off: una paleta de etiquetas un poco menos saturada.
Lee el código
El repositorio es público: los contratos de datos, las pruebas y el workflow de CI están ahí, con una descripción de la arquitectura en el README.
Ver el repositorio