Cuando una sección editorial nace al lado de un producto pequeño, casi cualquier estructura parece suficiente. Publicas una entrada, luego otra, añades un índice cronológico y sigues adelante. El coste de mezclar formatos no se nota porque todavía hay poco que mezclar. En Blupoli nos ocurrió exactamente eso. El primer Journal era una forma razonable de contar cómo crecía el proyecto, documentar un cambio técnico y, de vez en cuando, explicar una novedad importante para quien utilizaba la web. El problema apareció cuando esas tres cosas dejaron de ser la excepción y se convirtieron en tres líneas editoriales distintas.
En la misma superficie convivían un artículo sobre la arquitectura de motores, una guía de un puzzle, una actualización de marca, un texto sobre internacionalización, una explicación de onboarding, una noticia sobre nuevos idiomas y una entrada casi de diario sobre lo que habíamos aprendido al rehacer un juego. Todo era «contenido sobre Blupoli», pero no todo respondía a la misma pregunta. Quien llegaba buscando novedades de producto tenía que atravesar decisiones de implementación. Quien quería seguir el desarrollo encontraba piezas con tono de marketing. Y cuanto más escribíamos, más difícil se volvía entender qué era exactamente el Journal.
El rediseño reciente empezó como una petición visual —hacer el blog menos caótico, añadir imágenes, mejorar la estructura— y acabó convirtiéndose en una reestructuración de producto editorial. La conclusión fue sencilla de expresar y bastante más compleja de implementar: Blog y Devlog debían ser dos superficies distintas.
Separar por intención, no por tecnología
La primera decisión importante fue evitar una clasificación basada en cómo se había creado cada artículo. Podríamos haber separado «posts automáticos» de «posts manuales», «artículos largos» de «notas cortas» o «puzzles» de «infraestructura». Ninguna de esas divisiones resolvía el problema principal. Lo que importaba era la intención con la que una persona abre la sección.
El Blog debía responder a preguntas públicas: ¿qué ha cambiado en Blupoli?, ¿qué producto nuevo existe?, ¿por qué se ha rediseñado una parte de la web?, ¿qué puzzle merece una explicación?, ¿qué versión o funcionalidad queremos presentar? Es una publicación de marca y producto. Puede ser técnica cuando la historia lo necesita, pero no exige seguir el detalle del desarrollo.
El Devlog debía responder a una curiosidad diferente: ¿cómo se construyó?, ¿qué salió mal?, ¿qué decisión tomamos y por qué?, ¿qué trade-off apareció?, ¿qué aprendimos al auditar un motor?, ¿cómo cambió el repositorio o el pipeline? Es memoria de desarrollo. No tiene que disfrazarse de anuncio y no necesita convertir cada problema técnico en beneficio de marketing.
Esa separación nos permite escribir mejor porque cada artículo ya sabe qué promesa está haciendo.
La misma historia puede tener dos lecturas sin convertirse en dos copias.
El nombre «Devlog» ya no ayudaba
Durante un tiempo usamos «Devlog» como etiqueta para todo lo que contaba el proceso. Conceptualmente encajaba: queríamos hacer visible el desarrollo. Pero como nombre público de sección tenía dos problemas. Primero, describía una filosofía más que un tipo de contenido. Segundo, introducía una mezcla de idiomas y una terminología que necesitaba explicación justo donde queríamos claridad.
«Devlog» funciona mejor. Es corto, reconocible dentro del mundo del software y expresa que estamos hablando de un diario de desarrollo. En español podemos explicarlo como «diario de desarrollo» cuando haga falta, pero la marca visible sigue siendo compacta. Además nos permite mantener «Devlog» como idea interna o contexto histórico sin convertirla en la etiqueta principal de navegación.
Este cambio tenía una dimensión incómoda: el repositorio ya contenía nombres de archivos, scripts y estructuras con la nomenclatura anterior. Renombrarlo todo de golpe habría aumentado el riesgo sin aportar valor visible. Así que distinguimos entre identidad pública y compatibilidad interna. El usuario ve Devlog. Algunos archivos heredados todavía pueden llamarse devlog.json mientras completamos una migración segura. Esa tolerancia temporal es deliberada.
No queríamos perder 51 posts para ganar una estructura limpia
La separación editorial coincidía con una cantidad importante de contenido ya publicado. No era aceptable empezar de cero. Cada artículo tenía una URL, podía estar enlazado desde otro post, podía aparecer en buscadores y formaba parte de la historia del proyecto. La reestructuración tenía que clasificar y mejorar, no borrar.
Eso convirtió el trabajo en una migración. Los artículos se agruparon en categorías de Blog y de la antigua superficie de building public según su intención. El índice editorial pasó a expresar esas categorías de forma explícita. Al mismo tiempo, los scripts de build tuvieron que conservar las rutas que ya existían, generar las nuevas superficies y preparar redirecciones donde la arquitectura pública cambiaba.
La regla fue evitar una gran ruptura. Si una persona tenía guardado un enlace a un artículo técnico, ese enlace debía seguir funcionando. Si un post antiguo enlazaba a otro, no queríamos crear una red de 404 solo porque habíamos encontrado una taxonomía mejor. La arquitectura editorial podía evolucionar sin exigir que la historia pareciera recién nacida.
Las portadas dejaron de ser decoración opcional
Uno de los síntomas más evidentes del antiguo Journal era visual. Una lista larga de títulos, fragmentos y fechas funcionaba cuando había pocos artículos. Con decenas de entradas se convertía en una pared de texto. Era difícil escanear, difícil recordar y difícil distinguir una historia técnica de una guía o una noticia.
Por eso las portadas pasaron a ser obligatorias. No como stock decorativo, sino como parte de la identidad de cada historia. Una portada puede mostrar una metáfora del flujo técnico, una composición inspirada en el puzzle del que se habla, una separación visual entre dos sistemas o una síntesis de un cambio de producto. Debe ayudar a reconocer el artículo antes de leer el título completo.
El build incorpora validaciones relacionadas con estas imágenes: presencia, metadatos, texto alternativo y consistencia de las superficies editoriales. También empezamos a tratar las infografías como contenido. En un artículo técnico, un diagrama de estados puede explicar más que tres párrafos. En una guía, una representación de la mecánica puede ahorrar una explicación abstracta. La imagen deja de ser un requisito cosmético y se convierte en parte de la documentación.
Un mismo chrome para que Blog y Puzzles sigan siendo Blupoli
Separar superficies crea otro riesgo: que cada una empiece a parecer un sitio distinto. Eso ya se intuía en algunos puntos de la web. Había logos duplicados, variaciones del header, footers con tratamientos diferentes y pequeños cambios de botones que acumulaban divergencia. Si Blog, Devlog y Puzzles van a tener propósitos diferentes, la identidad compartida debe ser todavía más consistente.
Los commits recientes unifican precisamente esa capa. El logo pasa a ser un asset compartido en lugar de repetirse como marcas inline ligeramente distintas. La cabecera del blog usa el mismo lenguaje de marca que el resto del ecosistema. El footer también se alinea. Los componentes pueden contener destinos diferentes —Puzzles necesita acciones de juego que el Blog no necesita—, pero la forma del logo, el tratamiento de navegación, los estados visuales y la sensación general deben pertenecer a la misma familia.
Esta distinción entre «mismo componente» y «mismo contenido» es importante. Reutilizar no significa que todas las cabeceras tengan exactamente los mismos enlaces. Significa que no volvemos a diseñar la identidad desde cero en cada aplicación.
El rediseño editorial necesitaba build, no solo CSS
Podríamos haber creado dos páginas índice y filtrar tarjetas por categoría en el navegador. Habría sido rápido, pero habría dejado la separación en la capa más superficial. Queríamos que Blog y Devlog existieran como conceptos dentro del pipeline: con categorías explícitas, navegación, metadatos y generación coherente.
Eso explica la aparición de scripts de arquitectura editorial, normalización de metadatos, generación de portadas, migración de rutas, finalización SEO y quality gates. La cadena de build ya no se limita a copiar HTML. Interpreta qué tipo de artículo es cada pieza, completa metadatos, crea superficies derivadas, enlaza recursos, normaliza nombres y comprueba invariantes antes de publicar.
Hay un coste evidente: más scripts significan más puntos que mantener. Por eso intentamos que cada uno tenga una responsabilidad estrecha. Un script que normaliza el nombre Devlog no debería decidir el canon de SEO. Uno que genera una portada no debería reescribir rutas. Separar responsabilidades hace que una futura migración sea menos peligrosa y permite quitar compatibilidad antigua cuando deje de ser necesaria.
SEO obliga a tratar la arquitectura editorial como arquitectura real
Una sección editorial no cambia de nombre solo en el menú. Los buscadores conocen URLs, títulos, canonicales, datos estructurados, sitemaps y relaciones entre idiomas. Si movemos una historia sin actualizar esas capas, el sitio puede terminar mostrando dos versiones que compiten entre sí o señalando como canónica una ruta que ya no representa la estructura pública.
La reestructuración añadió validaciones para canonical, Open Graph, Twitter cards, publisher, BlogPosting y otras piezas que antes eran más inconsistentes. También se endureció el control de branding para que títulos antiguos no sigan terminando en una marca que ya no usamos públicamente. Y la localización del blog sigue teniendo que respetar el mismo slug, la misma fecha y el mismo autor entre idiomas.
Esto es especialmente importante porque la publicación de Blupoli convive con seis idiomas en el producto. No queremos resolver la traducción del contenido fingiendo que una versión española es inglesa. Si un artículo tiene traducción, debe ser una traducción real y el build genera canonicales y hreflang recíprocos. Si no la tiene, la ruta inglesa no debería publicar un duplicado en español solo para llenar un hueco.
El Blog y el Devlog necesitaban tonos distintos
La arquitectura técnica solo resuelve la mitad del problema. Podíamos separar rutas perfectamente y seguir escribiendo el mismo tipo de artículo en ambos lugares. Para evitarlo, definimos dos skills editoriales nuevas: write-blog y write-devlog. No son prompts decorativos. Funcionan como contratos de publicación.
La skill de Blog pide una voz pública: natural, útil, capaz de contar producto, marca, noticias o guías sin sonar a nota de prensa. La de Devlog exige evidencia de repositorio, decisiones concretas, trade-offs y honestidad sobre lo que sigue incompleto. Las dos exigen versiones completas en español e inglés, una portada, una o dos infografías, enlaces internos, revisión SEO y un bucle final de calidad.
La diferencia más importante está en lo que prohíben. Un Devlog no puede inventar un fallo interesante para hacer la historia más dramática. Un Blog no debería convertirse en un changelog técnico con un titular amable. Ambos formatos tienen que poder hablar del mismo cambio desde ángulos diferentes sin copiarse.
Publicar ya no es guardar HTML: es pasar por una cadena de evidencia, edición y validación.
Las fechas también forman parte de la narrativa
Otro problema del contenido anterior era temporal. Habíamos creado o rehecho muchas piezas en poco tiempo y varias terminaron con fechas muy próximas, aunque relataban fases que habían ocurrido a lo largo de semanas. El resultado era una publicación que parecía haber nacido de golpe. Además de resultar poco natural, destruía parte del valor documental del Devlog.
La solución no consiste en inventar fechas. Consiste en reconstruir la cronología a partir del desarrollo real y usar la fecha editorial de forma coherente. Algunas historias pertenecen al momento en que se tomó una decisión; otras son retrospectivas publicadas después y deben presentarse como tales. Lo importante es que el calendario no sea un artefacto del día en que ejecutamos un script de migración.
Queremos que dentro de unos meses el Devlog pueda leerse como memoria. Que se vea una progresión: primero el crecimiento del catálogo, luego los problemas de escala, después el onboarding compartido, las auditorías, la reestructuración de marca y ahora el paso a un modelo de calidad sobre cantidad. La fecha ayuda a ordenar ese relato.
El diseño de tarjetas tenía que contar más con menos
En una portada editorial con decenas de artículos, cada tarjeta compite por atención. Si todas tienen el mismo peso, el usuario termina leyendo títulos de arriba abajo. El nuevo diseño utiliza la imagen, la categoría, el tamaño tipográfico, el extracto y el espacio para crear una jerarquía más legible. La idea no es convertir la home en una revista sobrecargada; es permitir reconocer rápidamente qué tipo de historia hay delante.
Blog puede destacar una noticia de producto y agrupar guías o lanzamientos. Devlog puede dar prioridad a una historia reciente de arquitectura o proceso y mantener accesibles entradas anteriores por categoría. La taxonomía deja de ser una lista técnica y se convierte en navegación.
También estamos intentando que las portadas tengan suficiente identidad para que una parrilla no parezca generada por una plantilla. Eso exige evitar el recurso fácil de poner un gradiente y un icono genérico en todas. Los sistemas visuales pueden compartir tipografía, composición y paleta, pero cada historia debería introducir un elemento semántico que la haga reconocible.
Separar Blog y Devlog no significa aislarlos
Una de las decisiones editoriales más importantes es enlazar ambas superficies. Cuando una novedad de producto tiene una historia técnica interesante, el Blog puede enviar al Devlog para quien quiera profundizar. Cuando un Devlog explica una decisión que ya está visible en producción, puede enlazar al artículo de Blog o directamente al producto. Así evitamos escribir una única pieza imposible que intenta satisfacer a todos los públicos.
Los enlaces también conectan artículos antiguos. Un texto sobre motores puede apuntar a la auditoría de un juego concreto. Una entrada sobre diseño responsive puede relacionarse con la nueva unificación del header y el footer. Una noticia sobre el estado «próximamente» puede enlazar al Devlog donde contamos por qué la presencia en el repositorio dejó de equivaler a publicación.
Esta red importa tanto para lectura como para SEO. Un archivo editorial útil no es una pila cronológica; es un mapa de decisiones y temas donde cada nueva historia encuentra contexto.
La marca también estaba dispersa en el HTML
La migración de Blupoli Puzzles a Blupoli mostró otra fragilidad. Habíamos cambiado la identidad conceptual, pero todavía quedaban referencias antiguas en títulos, labels, scripts y fragmentos de HTML. Algunas eran históricas y debían conservarse. Otras eran simplemente residuos.
Los commits más recientes completan una limpieza amplia: Blupoli para la marca raíz, Blupoli Puzzles para el producto, títulos de navegador y metadatos coherentes, y un guard de build que detecta regresiones de branding legado en lugares donde ya no debería aparecer. Este tipo de verificación puede parecer exagerado hasta que un proyecto tiene suficientes superficies para que una cadena antigua reaparezca meses después.
La lección es parecida a la del contador de juegos: cualquier dato que dependa de una identidad global debería tener una fuente y una validación. Repetir texto manualmente en cincuenta páginas funciona hasta que deja de funcionar.
El footer móvil nos recordó que «compartido» no significa «resuelto»
Durante estos cambios también apareció un problema muy concreto: el footer no se veía correctamente en móvil. Es un buen ejemplo de cómo una reestructuración grande puede destapar fallos aparentemente pequeños que, sin embargo, afectan a toda la experiencia. El footer es navegación secundaria, acceso a la home, enlaces de producto y cierre visual. Si desaparece en una pantalla pequeña, la arquitectura de información queda incompleta precisamente donde más necesitamos simplicidad.
Rediseñarlo significó revisar no solo colores o cantidad de enlaces, sino su comportamiento responsive, la relación con la marca y la coherencia entre el host principal y Puzzles. El objetivo final es que header y footer sean piezas de chrome compartido: adaptables al contexto, pero no reinventadas por cada aplicación.
Este trabajo no tiene el glamour de una nueva mecánica, pero reduce la sensación de que estamos saltando entre webs independientes. En un ecosistema por subdominios, esos detalles son la costura visible.
Observabilidad entra en la misma conversación
La nueva arquitectura editorial coincide con otro cambio transversal: Firebase Analytics y una capa de observabilidad de errores web. No son features del Blog, pero afectan a cómo sabremos si el rediseño funciona. Hasta ahora muchas decisiones de navegación se tomaban observando manualmente la interfaz y razonando sobre el flujo. Eso seguirá siendo necesario, pero podremos complementarlo con señales reales y consentidas sobre qué superficies se usan.
La integración se ha planteado respetando consentimiento y CSP. El build inyecta la capa común en las distintas webs, y la configuración de seguridad se ajusta solo lo necesario para permitir los servicios utilizados. Queremos evitar la trampa de añadir analítica y relajar indiscriminadamente políticas de seguridad.
Con el tiempo, esto puede ayudarnos a responder preguntas editoriales reales: si la gente salta del Blog al Devlog, qué categorías se consultan, si determinadas páginas funcionan como entrada al catálogo o si algunos enlaces internos no se utilizan. No necesitamos instrumentar cada gesto; necesitamos suficiente información para validar decisiones de estructura.
Qué no está terminado todavía
La reestructuración ha avanzado mucho, pero no queremos describirla como un sistema cerrado. Todavía existen nombres internos heredados. El blog sigue viviendo en la infraestructura actual mientras la arquitectura de Blupoli prepara fronteras más claras entre blupoli.com, puzzles.blupoli.com y futuras superficies. Algunos artículos antiguos necesitan mejores traducciones o assets. Y la taxonomía seguirá ajustándose cuando tengamos más contenido real dentro de cada categoría.
También queda trabajo para reducir la cantidad de scripts de transición. Una migración sana acumula compatibilidad durante un tiempo y luego la retira. Si dentro de un año seguimos necesitando todos los normalizadores que existen hoy, significará que convertimos una etapa temporal en arquitectura permanente. No es el objetivo.
La ventaja es que ahora la dirección está definida. Sabemos qué ve el usuario, qué es legado, qué se genera y qué fuente de verdad gobierna cada superficie.
La publicación se ha convertido en parte del producto
Este es quizá el cambio conceptual más grande. Antes el contenido estaba alrededor del producto. Ahora la publicación es uno de los productos de Blupoli. Tiene navegación, identidad, reglas, calidad, localización, SEO, assets, pipeline y una audiencia con necesidades distintas. Eso justifica tratarla con el mismo cuidado que un juego o una home.
No significa que vayamos a publicar por publicar. De hecho, las nuevas skills endurecen el criterio. Cada artículo largo exige una historia que merezca la extensión, una edición en dos idiomas y recursos visuales que expliquen algo. La intención es reducir contenido superficial, no producir más páginas.
Blog y Devlog nos dan una estructura para hacerlo sin mezclar tonos. El Blog puede ser claro, visual y orientado a producto. El Devlog puede permitirse entrar en detalles de arquitectura, deuda, pruebas, decisiones y límites. Juntos cuentan Blupoli mejor que una única corriente que intentaba hacerlo todo.
Lo que aprendimos al reestructurar la memoria mientras seguíamos construyendo
Hacer esta migración en mitad de otros cambios —marca, dominios, catálogo, auditorías, diseño responsive, analítica— ha tenido una ventaja inesperada: nos obligó a comprobar si la estructura editorial podía soportar un proyecto en movimiento. Una taxonomía que solo funciona cuando todo está quieto no sirve para un Devlog.
Necesitábamos poder publicar una noticia sobre los juegos próximos y, al mismo tiempo, un artículo técnico sobre cómo se implementó ese estado. Necesitábamos contar el rediseño visual sin perder el detalle de los scripts que migraron artículos. Necesitábamos hablar de Blupoli como marca actual sin borrar la historia en la que Blupoli Puzzles era el nombre real del producto. Esas tensiones han sido una buena prueba del modelo.
La respuesta no ha sido crear más categorías. Ha sido definir mejor las fronteras y enlazarlas. Un buen sistema editorial no evita la complejidad del proyecto; la organiza para que una persona pueda elegir cuánto quiere profundizar.
Qué debería notar una persona y qué debería permanecer invisible
Si hacemos bien este trabajo, la mayoría de la arquitectura no debería llamar la atención. Quien entra en el Blog debería ver una publicación clara, bonita y fácil de recorrer. Quien abre el Devlog debería entender que está entrando en la trastienda del desarrollo. El logo, la navegación y el comportamiento visual deberían hacer evidente que ambos pertenecen a Blupoli. Los enlaces deberían funcionar. El idioma debería conservarse. Las imágenes deberían cargar. Nada de eso necesita explicar cuántos scripts participan.
La parte técnica existe precisamente para que esa sencillez sea sostenible. Para que añadir un artículo no requiera recordar manualmente veinte metatags. Para que una traducción no publique un canonical incorrecto. Para que una portada ausente falle antes del deploy. Para que una referencia de marca antigua no vuelva a colarse en el título del navegador.
Ese es el tipo de infraestructura que nos gusta: cuanto mejor funciona, menos se nota.
Una publicación con dos puertas de entrada
La versión anterior intentaba tener una sola puerta para todas las historias. La nueva acepta que hay dos. El Blog sirve para seguir Blupoli como producto y marca. El Devlog sirve para seguir cómo lo construimos. Ambos pueden hablar del mismo mes, incluso del mismo cambio, pero no deberían responder con el mismo texto.
En paralelo estamos reforzando la relación con el catálogo. Un artículo sobre un juego debe poder llevar a jugar cuando está publicado o explicar que está próximo cuando aún no lo está. Una historia de diseño puede enlazar a la superficie que ya incorpora el cambio. Una entrada técnica puede relacionarse con otras decisiones anteriores para formar una cadena de contexto.
Si quieres ver el origen de varias de estas decisiones, puedes continuar con la transición de Blupoli Puzzles a Blupoli, el trabajo para convertir las infografías en contenido editorial y el experimento que usa Git como materia prima para el Devlog. Y si lo que te interesa es el otro gran cambio de esta etapa, en Calidad antes que cantidad contamos por qué el catálogo también ha pasado de crecer por número a crecer por auditorías.
Esta separación no cierra la evolución del área editorial. La hace posible. Ahora cada nueva historia tiene un lugar, cada superficie sabe qué promete y el sistema puede seguir creciendo sin volver a convertirse en el batiburrillo que nos llevó a rediseñarlo.