Hay rediseños que empiezan porque algo se ve viejo. Este no. La Home de Blupoli tenía un problema más difícil de detectar: visualmente podía parecer correcta y, sin embargo, contar una historia equivocada sobre el producto. La portada había nacido cuando el proyecto estaba mucho más cerca de ser “una colección grande de puzzles con contenido alrededor”. Después llegaron la separación entre Blupoli y Blupoli Puzzles, el Blog y el Devlog como superficies editoriales propias, la infraestructura compartida de marca, el sistema de idioma común, el tema persistente, una arquitectura de monorepo más clara y la intención explícita de que Blupoli pueda alojar otros productos en el futuro. La página de inicio seguía arrastrando una jerarquía anterior.
Ese desfase era importante porque la Home no es solo una composición de tarjetas. Es la primera respuesta a una pregunta básica: “¿qué es Blupoli?”. Si la portada contesta “Puzzles, más un blog”, cualquier arquitectura futura tendrá que luchar contra esa expectativa. Si contesta “una plataforma donde publicamos productos digitales y documentamos el trabajo que los crea”, entonces Puzzles puede ser protagonista sin convertirse en el límite conceptual del proyecto. El trabajo reciente partió de esa diferencia. No queríamos decorar la misma estructura. Queríamos corregir el modelo mental que la estructura comunicaba.
El punto de partida: una Home válida para una etapa anterior
Antes de este rediseño, la portada ya había mejorado bastante respecto a las primeras versiones. Tenía navegación compartida, soporte responsive, modo claro y oscuro, contenido localizado y una separación más visible entre Blupoli y Puzzles. Sin embargo, el contenido seguía organizado alrededor de dos puertas principales: jugar y leer. Frases como “Two ways in” o “Puzzles is the current focus” eran honestas en el momento en que se escribieron, pero acabaron codificando una jerarquía demasiado estrecha. La plataforma aparecía como contexto; Puzzles aparecía como identidad.
El problema se hizo más evidente precisamente porque el resto del repositorio había avanzado. La migración de marca había eliminado referencias activas a Blupoli, la UI compartida empezaba a unir web principal y Puzzles, y Blog y Devlog ya no eran accesorios dentro del producto de juegos. Habíamos invertido en una capa de plataforma, pero la página más visible seguía explicando el conjunto desde el primer producto. Esa contradicción no rompía tests ni producía errores de consola. Era un fallo de arquitectura de información.
La auditoría de la Home formuló el objetivo de una manera deliberadamente concreta: blupoli.com debe percibirse como la plataforma de productos de Blupoli y no como una portada de Puzzles con un blog añadido. Esa frase se convirtió en el criterio que ordenó las decisiones posteriores. Si una sección reforzaba la plataforma, se quedaba. Si existía únicamente para explicar Puzzles como si fuese todo Blupoli, había que replantearla.
Rediseñar la Home significó redefinir la jerarquía, no añadir más bloques
Una salida fácil habría sido mantener la misma portada y añadir una nueva sección llamada “Productos”. Técnicamente sería sencillo, pero no solucionaría el problema. La jerarquía seguiría diciendo que el producto principal es Puzzles y que “Productos” es una idea adicional más abajo. Por eso el cambio empieza en el hero. El encabezado deja de describir una experiencia centrada en jugar y pasa a hablar de productos digitales, experimentos y del trabajo que hay detrás. La llamada principal ya no conduce directamente a un único producto: invita a explorar Blupoli. Puzzles conserva una CTA visible, pero como destino concreto dentro del ecosistema.
También comprimimos el hero. En una Home de plataforma, una portada demasiado alta puede consumir la primera pantalla en explicar una promesa abstracta. Queríamos que el primer producto real apareciera pronto y que la jerarquía “plataforma → productos” fuese visible sin obligar a hacer un scroll largo. El hero sigue teniendo personalidad, pero deja espacio para que el catálogo de productos tome el relevo rápidamente.
La segunda decisión fue separar categorías conceptuales que antes se mezclaban. Puzzles pertenece a Productos. Blog y Devlog pertenecen a la actividad editorial. Los experimentos son una posibilidad del sistema, no productos inventados. El trabajo activo se resume en una sección “Ahora” y el detalle se delega al Devlog. Esa separación parece semántica, pero tiene una consecuencia práctica: cada capa puede crecer por su cuenta sin obligar a la Home a fingir que todo es la misma cosa.
La portada deja de organizar Blupoli alrededor de un único destino y pasa a ordenar la experiencia por responsabilidades.
El hero se convirtió en un mapa del ecosistema
La parte visual del hero también cambió de función. Antes podía actuar como una ilustración del producto actual. Ahora representa el ecosistema. En el centro está Blupoli; alrededor aparecen Blupoli Puzzles, Blog, Devlog y un nodo futuro sin nombre ni promesa concreta. Esa última decisión es importante. Queríamos mostrar que la arquitectura está preparada para crecer sin caer en el error de inventar productos para que el diseño parezca más completo.
El nodo futuro no dice qué construiremos. Solo comunica que la estructura admite más productos. Esa distinción entre capacidad y roadmap es una de las ideas que hemos intentado preservar en todo el rediseño. Una plataforma creíble no necesita rellenar huecos con humo. Puede mostrar un sistema extensible y, al mismo tiempo, reconocer que hoy solo existe un producto publicado en su catálogo.
También usamos el mapa del ecosistema para reforzar los destinos reales. Cada nodo útil enlaza a una superficie concreta: Puzzles, Blog y Devlog. No es una ilustración decorativa colocada al lado del copy; forma parte de la navegación. Eso ayuda a que el hero explique la arquitectura a la vez que permite recorrerla.
Un archivo de productos reemplaza una promesa escrita a mano
El cambio técnico más importante de la nueva sección de productos no está en el HTML. Está en content/products.json. Hasta ahora, presentar Puzzles en la Home podía resolverse escribiendo su tarjeta directamente en la página. Eso funciona mientras solo existe un producto, pero crea un problema futuro: la estructura visible y el modelo de contenido quedan mezclados. Añadir otro producto obligaría a modificar el markup de la Home, recordar traducciones y volver a decidir qué campos necesita cada tarjeta.
La PR #108 introduce un registro canónico de productos. Hoy contiene exactamente uno: Blupoli Puzzles. Ese producto tiene identidad, tipo, estado, URL localizada, clave de traducción, plataforma y una pequeña lista de elementos representativos. La Home genera su catálogo a partir de esa fuente. No hay un segundo producto ficticio, ni una tarjeta “coming soon” con nombre provisional, ni una cifra inflada para vender una plataforma más grande de lo que es.
El valor de este cambio aparece cuando pensamos en el siguiente producto real. La pregunta deja de ser “¿cómo añadimos otra tarjeta parecida a Puzzles?” y pasa a ser “¿qué datos debe declarar un producto para entrar en Blupoli?”. Esa es una frontera más útil. La Home se convierte en renderer de una fuente de verdad, no en base de datos accidental.
Además, el build exige que exista al menos un producto. Es una condición pequeña pero significativa: si el registro se rompe, la portada no puede degradarse silenciosamente hasta mostrar una sección vacía. La plataforma depende de una fuente canónica y el pipeline lo reconoce.
Lo último ya no se escribe dos veces
La actividad reciente era otro punto donde una Home estática podía empezar a desalinearse. Blog y Devlog ya tienen su propio sistema editorial. Copiar manualmente tres enlaces recientes a la portada significaría mantener una segunda lista que puede quedarse obsoleta. La nueva sección “Lo último” evita esa duplicación: se alimenta de editorial-manifest.json, el mismo sistema que ya conoce los artículos y entradas de desarrollo.
Esto cambia el mantenimiento y también la percepción del sitio. La Home deja de ser una página que hay que “actualizar” cada vez que publicamos algo y pasa a reflejar la actividad editorial del proyecto. El contenido reciente se convierte en una consecuencia del pipeline, no en una tarea manual adicional.
El vínculo entre Home y editorial también refuerza una idea de producto: Blog y Devlog no son enlaces secundarios metidos en el footer. Son parte de la propuesta de Blupoli. El Blog sirve para historias, guías y piezas más editoriales; el Devlog registra decisiones, implementación y evolución. La portada los presenta como actividad viva del ecosistema sin confundirlos con productos vendibles o jugables.
El roadmap detallado salió de la portada
Una de las decisiones más útiles fue eliminar el roadmap largo que ocupaba una parte importante de la Home. No porque el roadmap deje de importar, sino porque estaba resolviendo el problema en el lugar equivocado. Una portada de plataforma necesita explicar identidad, productos y actividad actual. El detalle de “qué viene después” encaja mejor en una superficie editorial que pueda cambiar de ritmo sin convertir la Home en un tablero de proyecto.
Lo sustituimos por una sección compacta llamada “Ahora”. Resume tres líneas de trabajo verificables: seguir puliendo Blupoli Puzzles, reforzar la base compartida de la plataforma y documentar el trabajo real. Cada bloque explica una dirección, no promete una fecha. El CTA conduce al Devlog para quien quiera profundizar.
Este cambio reduce ruido y evita una tentación habitual: usar la portada para presentar planes como si fueran funcionalidades. La Home describe lo que Blupoli es y qué está haciendo ahora. El Devlog puede explicar la complejidad, los cambios de prioridades y las decisiones pendientes. Separar ambas funciones hace que la comunicación sea más honesta.
El rediseño necesitaba un sistema visual común de verdad
Mientras revisábamos la Home, apareció una deuda que no tenía sentido dejar intacta: los colores de marca seguían apareciendo en varias superficies mediante valores duplicados o nombres heredados. Eso era especialmente peligroso en un momento en que la web principal, Puzzles, Blog y Devlog estaban convergiendo visualmente. Podíamos conseguir una Home muy cuidada y, aun así, volver a introducir divergencia la siguiente vez que alguien ajustara un cyan o un violeta en un archivo distinto.
La solución fue convertir packages/ui/blupoli-design.css en la fuente canónica de la paleta de marca. Allí viven tokens como --brand-navy, --brand-cyan, --brand-indigo, --brand-violet, --brand-mint y el gradiente principal. La Home, el header, el footer y las superficies compartidas consumen esos tokens en lugar de redeclarar colores equivalentes.
La prueba automatizada no solo comprueba que los tokens existan. También busca que los estilos de la Home y Puzzles no vuelvan a introducir determinadas variantes antiguas ni variables paralelas como --accent donde ya no deben existir. Es un buen ejemplo del tipo de calidad que queremos: documentar una regla ayuda, pero convertirla en un fallo de test evita que dependa de memoria.
La internacionalización dejó de reemplazar frases
La Home ya estaba traducida a seis idiomas, pero el mecanismo anterior acumulaba una fragilidad clara: cada locale contenía listas de sustituciones de texto. Mientras la página fuese pequeña, reemplazar una frase inglesa por otra española, italiana o francesa podía parecer suficiente. En cuanto cambias el copy del hero, reorganizas secciones o reutilizas una palabra en dos contextos distintos, las sustituciones se vuelven difíciles de razonar y fáciles de romper.
El rediseño migró apps/web/home-i18n.json a claves semánticas. Ahora cada idioma declara estructuras como seo.title, hero.lead, products.puzzles.summary, latest.title, about.title y now.title. El template utiliza esas claves directamente. La relación entre contenido y UI deja de depender de que una frase original siga siendo idéntica.
Este cambio también obliga a pensar mejor en el contenido. “Abrir producto” y “Jugar a Puzzles” no son la misma cadena reutilizada por comodidad; cumplen funciones distintas y pueden necesitar traducciones diferentes. La estructura semántica hace visibles esas diferencias.
El test de la Home recorre EN, ES, IT, PT, FR y DE y exige que todos los paquetes tengan las secciones fundamentales. También comprueba que ya no exista la antigua propiedad de reemplazos. El build, por su parte, falla si quedan placeholders sin resolver o si una localización enlaza a una versión incorrecta de Puzzles. La internacionalización pasa de ser un paso posterior a formar parte del contrato de la página.
Navegación y footer también tuvieron que aceptar la nueva jerarquía
Una Home no puede declararse plataforma si el chrome compartido sigue ordenado como una web de un solo producto. Por eso la PR reorganiza header y footer alrededor de Productos, Blog, Devlog, Sobre Blupoli y Puzzles. Puzzles continúa siendo una acción destacada porque es el producto utilizable hoy, pero ya no absorbe toda la navegación.
Este ajuste se apoya en el trabajo previo que ya habíamos hecho para compartir el header y el footer entre superficies. En el Devlog sobre una interfaz sobre dos aplicaciones contamos por qué decidimos extraer identidad, idioma y navegación a una capa común en lugar de duplicar HTML. El rediseño de la Home aprovecha esa base: cambiar la jerarquía global puede propagarse desde componentes compartidos en vez de reconstruirse de forma independiente.
También importa para el crecimiento. Si mañana aparece un segundo producto, no debería exigir otra navegación “especial” solo para hacerlo visible. La estructura actual ya tiene un lugar conceptual para Productos y un CTA específico para Puzzles. Un producto nuevo puede entrar en el catálogo sin obligar a renombrar toda la plataforma.
La analítica mide destinos, no invade el diseño
Una Home de plataforma tiene otra pregunta que una página centrada en un solo producto no necesita responder con tanta precisión: ¿qué destino interesa realmente a quienes llegan? Para poder observarlo sin acoplar la interfaz a llamadas JavaScript dispersas, añadimos atributos data-analytics-* a las interacciones principales. El evento canónico es home_destination_click y distingue destinos y posiciones como hero, mapa del ecosistema o sección de actividad.
La instrumentación reutiliza la capa de observabilidad existente y respeta el modelo de analítica consentida. No convertimos cada tarjeta en un componente específico de tracking ni introdujimos dependencias de proveedor en el markup. La Home declara intención; la infraestructura decide cómo registrar el evento cuando corresponde.
El objetivo aquí no es presumir de métricas que todavía no tenemos. De hecho, no usamos ninguna mejora de conversión como argumento del rediseño porque no existe evidencia todavía. La instrumentación sirve para que, una vez publicada la nueva jerarquía, podamos observar si las rutas principales se comportan como esperábamos. Hasta entonces, el diseño se justifica por coherencia de producto y arquitectura, no por un número inventado.
El build ahora sabe reconocer una Home que ha retrocedido
Una de las partes más importantes del trabajo es que el rediseño no se limita a un conjunto de estilos. scripts/build-web.mjs incorpora reglas de regresión. La compilación falla si no se genera al menos un producto, si faltan las secciones esenciales de plataforma, si quedan placeholders semánticos sin resolver, si reaparecen copys heredados como “Two ways in” o “Puzzles is the current focus”, o si una variante localizada apunta al destino equivocado.
Además, test/home-platform.test.mjs valida la fuente de productos, la estructura de traducciones, la presencia de Productos, actividad reciente y la sección explicativa de plataforma, y la centralización de los colores de marca. Es una prueba deliberadamente orientada a arquitectura de producto. No pregunta si un margen mide 28 o 32 píxeles; pregunta si la Home sigue modelada como plataforma.
Ese matiz nos parece importante. Los tests visuales o snapshots pueden ayudar en otros niveles, pero aquí queríamos proteger las decisiones que más fácil sería deshacer accidentalmente durante una refactorización. Una persona podría cambiar el HTML, ver que “se ve bien” y sin darse cuenta volver a escribir Puzzles como identidad principal. El gate hace que esa regresión deje de ser silenciosa.
Datos, template, localización y build forman una cadena que impide que la portada vuelva a depender de copias manuales.
El rediseño no ocurrió aislado: necesitaba todo lo que construimos alrededor
La Home es la parte más visible de esta etapa, pero sería engañoso contarla como un cambio independiente. Durante los días anteriores consolidamos varias capas que hacen posible que esta nueva portada no sea otra isla. La migración de Blupoli a Blupoli dejó una identidad pública coherente y añadió guardas para impedir que el nombre antiguo reaparezca como marca activa. El logo se convirtió en recurso compartido. Header, footer y selector de idioma pasaron a ser piezas comunes entre la web principal y Puzzles.
También unificamos la preferencia de tema y la preferencia de idioma entre superficies. Eso significa que la Home puede enviar a una persona hacia Puzzles, Blog o Devlog sin que cada salto parezca entrar en un producto de otra familia. El diseño editorial se alineó con los tokens globales, y Blog y Devlog empezaron a consumir la misma base visual. El trabajo que documentamos en el sistema UI compartido y la separación entre Blog y Devlog es el contexto técnico directo de esta nueva Home.
Al mismo tiempo, Puzzles siguió madurando como producto independiente. El catálogo distingue juegos disponibles de próximos lanzamientos, la localización de payloads se hizo más estructural y se añadieron comprobaciones de paridad visual entre locales. Eso importa porque la plataforma no gana nada si su primer producto se vuelve ambiguo. La nueva Home puede presentar Puzzles como una entidad clara precisamente porque el producto tiene sus propias fronteras, estado y navegación.
Qué cambia para quien visita Blupoli
Desde fuera, la diferencia principal debería ser de comprensión. La persona que llega a Blupoli ya no necesita deducir si está entrando en una web de puzzles, un blog personal o una página corporativa. El hero explica que se trata de una plataforma de productos y trabajo en abierto. La siguiente sección muestra qué producto existe hoy. La actividad reciente ofrece contexto sin esconderlo en la navegación. Y una sección específica explica que Blupoli puede contener productos, experimentos y desarrollo documentado.
Ese recorrido también evita una promesa demasiado grande. No afirmamos tener una suite de aplicaciones. No mostramos productos que no existen. No tratamos una idea futura como si estuviese en beta. Blupoli Puzzles es el único producto disponible y se presenta con claridad. El resto de la estructura comunica capacidad de crecimiento, no inventario ficticio.
La navegación gana coherencia. Si alguien quiere jugar, Puzzles sigue a un clic. Si quiere entender cómo se construye el proyecto, Devlog es un destino de primer nivel. Si busca artículos y guías, Blog tiene su lugar. Si quiere saber qué es Blupoli, la Home ya no obliga a interpretar una mezcla de secciones heredadas.
Qué cambia para mantener el proyecto
La mejora más importante para mantenimiento es que varias cosas dejan de vivir en el HTML como decisiones ad hoc. Los productos se declaran en una fuente de datos. La actividad reciente viene del sistema editorial. Los colores de marca vienen del diseño compartido. Las traducciones usan claves semánticas. El header y el footer comparten jerarquía global. La analítica declara eventos mediante atributos. Y el build conoce invariantes concretas de la página.
Eso reduce el número de lugares que hay que recordar cuando cambiemos algo. Un nuevo producto no debería requerir editar media docena de bloques estáticos. Un cambio de paleta no debería perseguir hexadecimales dispersos. Un nuevo copy del hero no debería romper un sistema de sustituciones de frases. Una nueva localización no debería poder publicarse sin las secciones principales. Cada uno de esos problemas sigue teniendo trabajo, pero ahora tiene una frontera más clara.
También mejora la capacidad de revisar una PR. En lugar de preguntar solo “¿se ve bien?”, podemos preguntar: ¿el producto está declarado en la fuente canónica?, ¿la Home lo renderiza?, ¿todos los locales tienen las claves?, ¿el build detectaría un placeholder?, ¿el diseño consume tokens compartidos?, ¿la navegación sigue describiendo la plataforma? La calidad se vuelve más inspeccionable.
Lo que decidimos no hacer
Hubo varias cosas que deliberadamente quedaron fuera. No creamos nombres para productos futuros. No añadimos una cuenta Blupoli a la Home como si ya existiera. No convertimos el nodo “más productos” en un roadmap público. No usamos cifras fijas de juegos como argumento principal de la plataforma, porque ese tipo de número envejece rápido y además pertenece a Puzzles, no a la identidad completa de Blupoli.
Tampoco intentamos resolver toda la arquitectura de contenidos futuros dentro del registro de productos. content/products.json es pequeño porque hoy el problema es pequeño. Tiene la información suficiente para renderizar Puzzles y establecer el contrato inicial. Cuando aparezca un segundo producto real tendremos evidencia para decidir si hacen falta campos nuevos, distintos estados o agrupaciones. Diseñar veinte propiedades hipotéticas ahora sería otra forma de acoplamiento.
Y no eliminamos toda referencia técnica heredada del repositorio solo por estética. Algunas rutas y archivos siguen conservando nombres históricos por compatibilidad con el pipeline. Como ya aprendimos en la migración editorial, la identidad pública puede avanzar sin obligarnos a romper infraestructura estable en la misma PR. La regla es que lo heredado no gobierne las nuevas decisiones.
Validación: lo que sabemos y lo que todavía no podemos afirmar
En el momento de escribir esta entrada, el rediseño vive en la PR #108, feat/home-platform-redesign. La PR está abierta y GitHub la reporta como mergeable. Esto es importante porque el Devlog debe distinguir entre “implementado en una rama revisable” y “publicado en producción”. La historia que contamos aquí corresponde al trabajo real del branch: archivos, tests, audit, build y estructura de datos. No estamos afirmando que cada visitante de blupoli.com ya esté viendo esta versión.
La validación de fuente incluye test/home-platform.test.mjs, que comprueba registro de productos, claves semánticas de los seis locales, paleta canónica y derivación de contenido desde las fuentes correctas. El build incorpora sus propias condiciones de fallo. La auditoría docs/audits/blupoli-home-platform.md resume los cambios y las reglas de regresión que esperábamos conseguir.
Lo que todavía no tenemos son métricas de comportamiento posteriores al despliegue. Hemos instrumentado los clics principales para poder observar destinos, pero no existe base para decir que la nueva Home mejora la conversión, el tiempo de sesión o cualquier otro indicador. Tampoco debemos confundir “mergeable” con “validado en todos los navegadores posibles”. La revisión visual y la observación posterior al despliegue seguirán siendo necesarias.
La lección: una Home puede ser una pieza de arquitectura
La idea más útil que nos deja este rediseño es que una página de inicio no es solo marketing. En una plataforma que pretende crecer, la Home codifica fronteras. Decide qué es marca, qué es producto, qué es contenido editorial, qué es actividad actual y qué es futuro. Si esas categorías se mezclan, el código termina reflejando la misma confusión: tarjetas hardcodeadas, traducciones por reemplazo, colores duplicados, enlaces manuales y roadmaps que parecen funcionalidades.
Al separar esas responsabilidades, el diseño y la arquitectura empezaron a empujarse en la misma dirección. El registro de productos existe porque “Productos” es una categoría real. El manifiesto editorial alimenta “Lo último” porque Blog y Devlog son una capa propia. Las claves semánticas existen porque el contenido de la Home tiene estructura estable. Los tokens compartidos existen porque Blupoli debe parecer la misma familia en varias superficies. Los gates existen porque algunas decisiones son demasiado importantes para depender de recordar un documento.
Esto conecta con el camino que ya habíamos abierto al pasar de una colección de más de setenta juegos a un producto que necesitaba descubrimiento, categorías y estados reales. En el rediseño del catálogo para 71+ juegos aprendimos que la escala rompe las listas planas. Ahora la escala que estamos preparando es distinta: no más juegos dentro de Puzzles, sino más tipos de cosas dentro de Blupoli. La respuesta vuelve a ser la misma en el fondo: cuando una estructura va a crecer, conviene modelarla antes de que la interfaz se convierta en su base de datos accidental.
También continúa la transición de marca explicada en Blupoli cambia de piel. Cambiar un nombre era solo el primer paso. Darle a la marca una jerarquía propia, un sistema visual común, navegación compartida y una Home que no confunda plataforma con primer producto es lo que convierte esa transición en arquitectura real.
Qué queda después de esta Home
El rediseño deja una base, no una conclusión definitiva. Cuando la PR se integre, habrá que observar el comportamiento real, revisar la composición en tamaños de pantalla variados y confirmar que las rutas localizadas y los destinos externos funcionan como esperamos en producción. Si el tracking consentido empieza a aportar datos suficientes, podremos evaluar qué destinos se usan y dónde existe fricción. Esa evidencia puede justificar cambios posteriores; no necesitamos anticiparlos ahora.
También habrá que mantener disciplinado el registro de productos. La ventaja de una fuente canónica desaparece si empezamos a añadir excepciones directamente en el template. Lo mismo ocurre con el sistema visual: centralizar los colores solo sirve si las nuevas superficies consumen tokens en lugar de crear una paleta paralela. Y la i18n semántica será útil si las nuevas secciones se incorporan con claves, no reintroduciendo sustituciones de texto por rapidez.
La siguiente prueba de esta arquitectura llegará cuando Blupoli tenga algo nuevo que publicar además de Puzzles. En ese momento sabremos si el contrato de producto es suficientemente general o si necesita evolucionar. Hasta entonces, la decisión correcta es mantenerlo pequeño, explícito y respaldado por un producto real.
De una portada que describía el presente a una que permite crecer
El resultado de esta etapa no es “una Home más bonita”, aunque visualmente el cambio sea importante. Es una portada que representa mejor el sistema que estamos construyendo. Blupoli ocupa el centro como plataforma. Blupoli Puzzles aparece como primer producto disponible. Blog y Devlog muestran actividad y contexto. Los experimentos tienen un lugar conceptual sin fingir que ya son productos. El trabajo actual se resume sin convertir la portada en backlog. Y detrás de esa jerarquía hay fuentes de datos, traducciones estructuradas, tokens compartidos, observabilidad y tests que intentan conservarla.
Ese tipo de rediseño es menos espectacular que una reescritura completa y bastante más útil. No cambia de framework, no reinventa el repositorio y no borra todo lo anterior. Aprovecha las capas que ya habíamos construido y corrige la parte que todavía contaba una historia antigua. La Home deja de ser un escaparate centrado en el primer producto y se convierte en el índice de una plataforma que todavía es pequeña, pero que ya sabe cómo quiere crecer.
Y quizá esa sea la señal más clara de madurez en esta fase: no necesitamos llenar Blupoli de cosas para que parezca una plataforma. Necesitamos que las pocas cosas que existen tengan fronteras claras, una identidad coherente y un sistema capaz de admitir la siguiente sin romper las anteriores. El rediseño de la Home es, sobre todo, la formalización visible de esa idea.