TL;DR

Entre el 11 de junio y el 16 de julio hice 58 commits en esta web. Lo que empezó como una puesta al día terminó convirtiéndose en un nuevo diseño, una actualización a Astro 7 y, sobre todo, una reconstrucción completa de la forma de publicar: Sanity salió del proyecto y todos los posts pasaron a MDX local, bilingüe y validado junto al código.

La web no está «terminada», porque seguramente nunca lo estará. Pero ya vuelve a cumplir su función: automotivarme, permitirme publicar y dar contexto a mis juegos sin reclamar toda mi atención.

Cuando una puesta al día deja de serlo

No tenía planeado dedicar un mes entero a SenseiSoloDev.com. Había cambios pendientes, partes que quería ordenar y algunas ideas que no terminaban de encajar en la estructura anterior. Una mejora llevó a otra y, cuando quise darme cuenta, le había dedicado más tiempo del que había anticipado.

Los primeros commits fueron poco vistosos para quien visitaba la web: dependencias, rutas, locales, configuración, middleware y varios ajustes para Cloudflare. Trabajo invisible, pero necesario para dejar de construir encima de decisiones antiguas.

Después llegó la parte que sí se ve.

Una web con más sitio para mí

Renové la navegación, rediseñé la portada, los listados, los artículos y las páginas de proyectos. También actualicé la base a Astro 7 y añadí My Shelf, una publicación mensual donde puedo reunir los juegos, libros, series y cacharros que me han acompañado durante el mes.

Ese apartado marcó bastante bien la dirección que quería seguir. La web no debía ser únicamente un escaparate para dos videojuegos y un archivo de posts. Tenía que representar mejor todo lo que hago y consumo alrededor del desarrollo.

El nuevo diseño resolvía la parte visible, pero la reconstrucción importante estaba ocurriendo por debajo.

Adiós a Sanity, hola de nuevo a los archivos

Hasta entonces, el contenido dependía de Sanity y de un Studio separado. Durante la migración moví los posts y sus imágenes al propio repositorio mediante Astro Content Collections y MDX.

Ahora cada publicación vive en dos archivos cuando está publicada en ambos idiomas:

src/content/posts/es/
src/content/posts/en/

Las dos versiones comparten una translationKey, pero pueden tener títulos, slugs, descripciones y enlaces naturales para cada idioma. Las imágenes también son locales y el repositorio vuelve a ser la fuente de verdad de lo que termina desplegado.

No es una crítica a Sanity. Simplemente, para esta web y para mi forma actual de trabajar, mantener contenido y código dentro del mismo flujo encaja mejor. Puedo revisar una publicación, su traducción, los assets y el resultado de la build sin cambiar de contexto.

Eliminar el CMS tampoco consistía solo en copiar archivos. Hubo que reconstruir listados, páginas de detalle, relaciones entre traducciones, tags, navegación entre artículos, proyectos relacionados y el sitemap. Esa fue la parte que convirtió una migración de contenido en un cambio real de arquitectura.

Publicar sin volver a romperlo todo

Una vez migrado, el siguiente objetivo fue evitar que cada post nuevo dependiera de mi memoria.

Añadí validación específica para comprobar el frontmatter, los slugs, los locales, las parejas ES/EN, los tags y los assets. Centralicé rutas, separé componentes demasiado grandes y reforcé el SEO con canonical, alternates, JSON-LD y un sitemap generado desde el contenido real.

También configuré caché immutable para las portadas versionadas, eventos personalizados de Umami y medición de Core Web Vitals. Esto último no significa que todo haya mejorado mágicamente: significa que ahora tengo datos para detectar si una decisión empeora la experiencia.

Y, como último paso, convertí el workflow completo de publicación bilingüe en una Agent Skill local. La idea es sencilla: que el agente pueda ayudarme a crear la pareja ES/EN, comprobar la portada, validar el sitemap y cerrar Trello siguiendo siempre el mismo proceso. De hecho, este artículo es la primera prueba real de esa skill.

La mejor validación era volver a publicar

Toda esta infraestructura tendría poco sentido si la web siguiera vacía o parada. Durante estas semanas publiqué la edición de julio de My Shelf, una reflexión sobre el formato físico, la página de trello-sync y su primer devlog.

También añadí el widget Mi estado, que muestra qué estoy jugando, leyendo y viendo sin obligarme a convertir cada actualización pequeña en una publicación. En escritorio aparece abierto por defecto pero puede plegarse; en móvil se transforma en un panel compacto para no ocupar media pantalla.

Son añadidos distintos, pero todos responden a la misma idea: que la web se sienta viva aunque pase la mayor parte del tiempo metido en algún engine de videojuegos.

El peligro de construir la herramienta perfecta

Me gusta desarrollar herramientas y mejorar procesos. El problema es que siempre hay una refactorización más, otra métrica que añadir o una sección nueva que podría quedar mejor.

La web puede convertirse fácilmente en una forma muy productiva de posponer el desarrollo de mis juegos.

Por eso no quiero cerrar esta etapa diciendo que SenseiSoloDev.com está terminada. No lo está, pero sí se encuentra suficientemente preparada. Puedo publicar en español e inglés, enseñar mis proyectos, añadir formatos nuevos y detectar errores antes del despliegue sin tener que reconstruir el sistema cada vez.

Eso era lo que necesitaba.

Volver a la actividad normal

Para mí, volver a la normalidad no significa publicar por obligación todas las semanas. Significa que la web deja de ser el centro y vuelve a acompañar lo que realmente quiero hacer: desarrollar videojuegos, compartir avances cuando haya algo interesante y mantener espacios como My Shelf sin convertirlos en otra carga.

Seguiré tocando cosas, porque sé que no puedo evitarlo. Pero, a partir de ahora, cada mejora tendrá que responder a una pregunta bastante sencilla: ¿me ayuda a crear y compartir?