De PuzzleHub a Blupoli: cuando un catálogo se convierte en un ecosistema

Hay cambios que empiezan como una decisión de naming y terminan obligándote a revisar arquitectura, despliegue, navegación, SEO, dominios y hasta la manera en la que explicas el proyecto. Eso es exactamente lo que nos ha pasado al pasar de PuzzleHub a Blupoli.

PuzzleHub nació como una web de puzzles. El nombre describía bien el producto y durante meses fue suficiente. Pero el proyecto empezó a crecer en dos direcciones a la vez. Por un lado, el catálogo dejó de ser una pequeña colección y se convirtió en una plataforma con decenas de juegos, motores propios, internacionalización, estadísticas, onboarding, temas y una publicación editorial alrededor del desarrollo. Por otro, empezaron a aparecer ideas que ya no cabían bajo la palabra «puzzle»: recursos imprimibles, posibles productos para niños, entrenamiento mental, libros y una capa de marca que queríamos conservar aunque el catálogo evolucionara.

En ese punto, renombrar no consistía en sustituir un logotipo. Había que decidir qué era el producto, qué era la marca y qué partes debían poder crecer por separado sin convertirse en proyectos aislados.

La pregunta no era cómo renombrar PuzzleHub

La pregunta útil era otra: ¿qué queremos que siga teniendo sentido dentro de dos o tres años? Si Blupoli acaba teniendo Puzzles, un área Kids, recursos descargables, una tienda ligera o nuevas experiencias, el dominio raíz no puede estar diseñado como si uno de esos productos fuera necesariamente «el principal» para siempre.

Eso nos llevó a separar tres niveles que antes estaban mezclados. Blupoli es la marca. Puzzles es un producto. El blog es una publicación sobre la construcción del conjunto. Esa distinción parece trivial escrita en una frase, pero cambia muchas decisiones técnicas.

Por ejemplo, blupoli.com ya no necesita contener el catálogo completo de juegos. Puede ser una portada breve que explique qué existe, muestre la hoja de ruta y lleve a cada producto. puzzles.blupoli.com puede optimizarse sin concesiones para jugar. Y el blog puede evolucionar hacia blog.blupoli.com sin arrastrar navegación de producto que no le corresponde.

Una marca raíz no debería obligar a todos sus productos a fingir que son la misma página.

Subdominios como frontera de producto, no como decoración

Nos gusta la estructura por subdominios porque expresa una frontera real. No estamos creando puzzles.blupoli.com para que la URL parezca más bonita. Lo hacemos porque Puzzles tiene su propio ciclo de producto, su catálogo, su UI, sus estadísticas y, en el futuro, puede tener necesidades de despliegue distintas al portal corporativo.

La misma lógica sirve para otras áreas que todavía no existen o que solo están planteadas. brain.blupoli.com, kids.blupoli.com o store.blupoli.com no tienen por qué aparecer hoy en la navegación ni convertirse en promesas. Lo importante es que la arquitectura no nos obligue a rehacerlo todo si algún día tienen sentido.

También estamos separando el blog. Durante la primera etapa, el Journal vivía dentro de PuzzleHub porque todo el proyecto era PuzzleHub. Ahora el contenido habla de infraestructura, agentes, Firebase, producto, diseño, dominios y decisiones que afectan a Blupoli completo. Mantenerlo como una sección de Puzzles convertiría al producto en propietario editorial de una historia que ya lo supera.

Un solo proyecto Firebase, varios sitios de Hosting

La separación visual no significa que queramos multiplicar la infraestructura sin necesidad. Una de las decisiones más importantes de esta migración ha sido mantener un único proyecto Firebase llamado Blupoli y utilizar varios sitios de Firebase Hosting dentro de él.

El sitio raíz sirve blupoli.com. Otro sitio sirve Puzzles. Más adelante podremos añadir el blog como otro Hosting site. Esto nos da despliegues y dominios independientes sin fragmentar servicios compartidos como autenticación o datos.

La alternativa —crear un proyecto Firebase distinto para cada subdominio— habría parecido más «limpia» sobre el papel, pero habría introducido una separación que no queremos. Nuestro objetivo a medio plazo es una cuenta Blupoli capaz de acompañar a una persona entre productos. Si cada producto nace en un proyecto aislado, compartir identidad, permisos y determinadas capas de datos se vuelve más complejo desde el principio.

Hay un matiz importante: compartir proyecto también significa compartir determinadas cuotas y límites. No es una decisión gratis. Pero en nuestro caso pesa más la coherencia de identidad y la simplicidad operativa actual que optimizar por anticipado una escala que todavía no necesitamos.

La cuenta común condiciona la arquitectura antes de existir

Aún no hemos construido la cuenta Blupoli definitiva, y precisamente por eso resulta útil pensarla ahora. Las decisiones más caras suelen ser las que parecen inocuas mientras una funcionalidad todavía no existe.

Queremos que una persona pueda, en el futuro, iniciar sesión una vez y conservar estadísticas, preferencias o progresos de productos compatibles. Eso no significa mezclar todas las bases de datos ni obligar a que cada aplicación lea todo. Significa que la identidad principal debe poder ser común y que cada producto tenga después su propia frontera de datos.

Esta visión también explica por qué evitamos convertir Puzzles en «la web principal» y luego añadir productos como rutas internas. Puzzles debe poder tener sus propias decisiones técnicas sin convertirse en el contenedor obligatorio de todo lo demás.

El monorepo deja de ser una carpeta grande y empieza a expresar arquitectura

El repositorio también está cambiando de identidad. La dirección es un monorepo ArceApps/blupoli con aplicaciones separadas y paquetes compartidos. La home de marca ya vive bajo apps/web; Puzzles debe terminar viviendo de forma explícita como aplicación independiente; y el código común tendrá su sitio en packages/ cuando exista suficiente reutilización real para justificarlo.

Esto es importante porque «monorepo» puede degenerar rápidamente en «todo está en el mismo sitio». No queremos eso. Queremos que la estructura haga visibles las fronteras. Una aplicación puede desplegarse sola. Un paquete común tiene un propósito claro. Los scripts de build saben qué están generando. La configuración de Hosting apunta a destinos concretos.

Durante la transición todavía conviven piezas antiguas con la arquitectura objetivo. Puzzles sigue generando un dist desde su raíz histórica, mientras la home nueva ya está separada. Preferimos esa migración incremental a una gran reestructuración que cambie cientos de rutas a la vez y complique distinguir errores de arquitectura de errores de movimiento de archivos.

Despliegues: de GitHub a nuestro propio runner

Otro cambio que parece independiente pero forma parte del mismo proceso es el despliegue. Ya teníamos GitHub Actions publicando Firebase Hosting, y queríamos seguir conservando la automatización. Lo que cambiamos fue dónde se ejecuta.

Ahora los despliegues pueden correr en un runner self-hosted de nuestro Mini PC. GitHub sigue siendo el coordinador: un push, una rama o un workflow disparan el trabajo. Pero la máquina que instala dependencias, verifica el proyecto y ejecuta Firebase CLI puede ser infraestructura nuestra.

No hacemos esto porque un runner propio sea automáticamente «mejor». Tiene costes de mantenimiento, seguridad y disponibilidad. Lo hacemos porque encaja con una infraestructura doméstica que ya utilizamos para otros repositorios y nos permite mantener un flujo homogéneo, controlar el entorno y no depender de minutos de ejecución ajenos para procesos que podemos asumir nosotros.

Los dominios obligan a hacer visibles decisiones que antes estaban escondidas

Comprar blupoli.com fue la parte sencilla. Conectarlo correctamente nos obligó a revisar DNS, parking del registrador, registros A, CNAME, TXT de verificación y el comportamiento de Firebase con dominios personalizados.

Un detalle interesante fue descubrir que el registrador mantenía registros automáticos mientras el dominio estaba configurado con una página de presentación. Desde la interfaz DNS parecía que no podíamos eliminar ni editar el A antiguo. La solución no estaba en el formulario del registro, sino un nivel más arriba: cambiar el dominio a gestión libre para recuperar control real sobre las entradas DNS.

Este tipo de problema es un buen ejemplo de por qué nos gusta contar el proceso. En una documentación final se escribiría simplemente «apunta el dominio a Firebase». En la práctica, la dificultad está muchas veces en descubrir quién controla de verdad el valor que estás intentando cambiar.

Una home de marca tenía que ser pequeña

Cuando por fin tuvimos un sitio independiente para Blupoli, apareció otra tentación: llenar la portada de productos futuros, promesas y secciones. Decidimos hacer lo contrario.

La primera versión de la home mostraba Puzzles y una idea futura llamada Brain. La retiramos casi inmediatamente. No porque Brain sea una mala idea, sino porque una portada de marca no debería inventarse un catálogo antes de tener productos reales. Hoy Blupoli necesita explicar qué es, abrir Puzzles, conectar con el blog y mostrar una hoja de ruta honesta. Eso es suficiente.

La reducción también ayuda a diseñar mejor. Con menos destinos podemos dar más espacio a la identidad visual, mantener el logo y la paleta común, hacer que la navegación sea obvia y evitar tarjetas de «próximamente» que envejecen sin aportar nada.

Modo claro y oscuro como parte de la identidad compartida

Puzzles ya había aprendido una lección importante con el modo claro: un tema no es cambiar el color del fondo. Es comprobar que bordes, superficies, estados, textos secundarios, tableros y controles no dependen accidentalmente de una sola luminancia.

La home de Blupoli ahora hereda ese mismo principio. El tema inicial respeta la preferencia del sistema, el usuario puede cambiarlo, la selección se persiste y el color del navegador también se sincroniza. La implementación es sencilla; lo valioso es convertirla en una expectativa compartida entre productos.

Además, esta pequeña funcionalidad destapó una restricción de seguridad real. La Content Security Policy de la home se había definido inicialmente con script-src 'none', algo razonable cuando la página no ejecutaba JavaScript. Al añadir el selector de tema, el script propio quedaba bloqueado. En lugar de relajar toda la política, la ajustamos a script-src 'self'. El resultado es una home interactiva sin abrir la puerta a scripts de terceros.

El blog ya no es marketing: es memoria del sistema

Durante estas semanas el Journal ha pasado de ser una colección de artículos a una pieza del flujo de desarrollo. Tenemos entradas largas, devlog, Building in Public, series, roadmap, diagramas y un proceso que usa Git como una de las fuentes para recordar qué ha cambiado.

Eso hace todavía más evidente que el blog merece identidad propia dentro de Blupoli. No queremos que una persona tenga que «entrar en Puzzles» para leer cómo montamos Firebase, por qué usamos un runner self-hosted o cómo decidimos la arquitectura de subdominios.

La migración física no se hará de golpe. Mientras el blog siga publicado bajo las rutas actuales, mover canonicales o borrar URLs sería peor que convivir un poco con la transición. La intención es crear el sitio independiente, publicar allí, añadir redirecciones permanentes y solo entonces considerar completada la separación.

La hoja de ruta pasa a la raíz

Otra consecuencia de tener una marca por encima de los productos es que necesitamos dos escalas de roadmap. Puzzles tiene su backlog técnico y de producto. Blupoli necesita una vista mucho más pequeña: qué producto está activo, qué estamos consolidando y qué direcciones estamos explorando.

La home raíz ya muestra esa capa. Por ahora casi todo gira alrededor de Puzzles porque es lo que existe. No queremos rellenar el roadmap con nombres de productos hipotéticos para que parezca más grande. A medida que haya nuevas áreas reales, la hoja de ruta podrá incorporar hitos de marca sin convertirse en un duplicado de las tareas internas.

Lo más difícil del rebranding no ha sido el logo

El logo prácticamente se mantuvo. La paleta también. La parte costosa ha sido descubrir qué significaba realmente el cambio de nombre.

Cuando un proyecto todavía es pequeño, nombre, dominio, repositorio, producto y empresa pueden parecer la misma cosa. Al crecer, esas capas empiezan a pedir independencia. Si esperas demasiado, separarlas puede ser traumático. Si las separas demasiado pronto, construyes arquitectura para un futuro imaginario.

Estamos intentando quedarnos en medio. Blupoli existe porque ya había señales concretas de que PuzzleHub estaba superando el alcance de su nombre. Pero Brain, Kids, Store o Ágora solo se convertirán en productos cuando haya una necesidad suficientemente clara. La arquitectura admite esas posibilidades sin obligarnos a fingir que ya forman parte de la oferta.

Qué queda por hacer

La transición está lejos de terminar. Falta completar la estructura del monorepo, adaptar workflows que todavía conservan nombres antiguos, trasladar el blog a su propio Hosting site, revisar canonicales y redirecciones, terminar de eliminar referencias históricas donde ya no aportan contexto y conectar los dominios definitivos.

También queda una decisión importante: hasta dónde queremos compartir infraestructura entre productos. Una cuenta común no implica que todo deba compartir base de datos, despliegue o UI. Tendremos que encontrar el punto exacto donde reutilizar reduce complejidad sin borrar fronteras.

Pero la parte esencial ya está decidida: Blupoli no será una carpeta donde metamos cualquier idea. Será una marca raíz pequeña, con productos que puedan crecer de forma independiente y una infraestructura que permita compartir solo aquello que realmente tiene sentido compartir.

Ese cambio nos parece más importante que el nombre nuevo. PuzzleHub nos enseñó a construir una plataforma de puzzles. Blupoli es el intento de construir una casa suficientemente flexible para que Puzzles pueda seguir creciendo sin tener que cargar sobre sus hombros todo lo que venga después.