Some product changes arrive disguised as branding work. You think you are choosing a name or moving a logo, and a few days later you are discussing DNS records, Firebase Hosting targets, repository boundaries, canonical URLs and how a future account should identify a person across more than one application.
That is roughly what happened here. The original web project was a puzzle catalogue. For a while, product, brand and website were close enough to feel like the same thing. Then the catalogue grew into something much broader: many games, native engines, shared UI, onboarding, statistics, internationalisation and a substantial editorial record around how the whole thing was being built.
At the same time, the work around it started producing ideas and capabilities that were not inherently “a puzzle catalogue”. Once that happens, a single product cannot keep pretending to be the root of everything. We needed a clearer model: Blupoli as the umbrella brand, Blupoli Puzzles as the puzzle product, and editorial or future product surfaces able to grow without being forced through the same interface.
The useful question was not “how do we rename it?”
The useful question was: what structure will still make sense if Blupoli is larger in two or three years? A brand architecture should not assume that today’s most mature product will always be the container for every future idea.
That led us to separate three concepts that had been easy to mix. Blupoli is the root identity. Puzzles is a product with a very specific job: help people discover and play logic games. The Blog and Devlog are publishing surfaces whose job is to explain product stories, architecture, experiments and lessons. Those pieces are connected, but connection does not require them to share every navigation item or deployment boundary.
The distinction changes practical decisions. blupoli.com can remain a concise root rather than a second copy of the puzzle catalogue. puzzles.blupoli.com can optimise aggressively for play. Editorial publishing can evolve around reading, feeds and long-form navigation. A future product can join the same brand without first masquerading as a subsection of Puzzles.
Subdomains should describe product boundaries, not decorate URLs
We do not want a new subdomain for every small feature. A subdomain earns its place when the surface has a purpose, navigation model and lifecycle that are sufficiently independent. Blupoli Puzzles meets that test. It has a catalogue, game routes, progression, statistics and interaction patterns that make sense together.
The same principle protects us from over-planning. It is easy to reserve names for hypothetical products and then turn architecture into a mood board. We prefer the opposite: design the system so a future product could have an independent home, but do not present that home publicly until there is something real behind it.
Editorial publishing is a useful intermediate case. Early on, keeping the Journal close to the puzzle product was reasonable because almost every story was about the same surface. As articles started covering hosting, AI-assisted workflows, design systems, Android strategy and brand architecture, the content clearly belonged to Blupoli as a whole.
One Firebase project can host several public surfaces
Clear product boundaries do not automatically require duplicated backend projects. One of the decisions behind the transition was to keep a common Firebase project while using multiple Hosting sites. The root site and Puzzles can deploy independently and use their own domains without forcing us to fragment every shared service.
That matters because identity is one of the few capabilities we expect could genuinely span products. A future Blupoli account should not require someone to become a different person simply because they moved from one Blupoli surface to another. Keeping the foundation compatible with shared authentication is easier than reconstructing that relationship after several isolated projects have already evolved separately.
There is a trade-off. Shared projects also mean shared operational concerns and quotas. We are not claiming that one Firebase project is the universal answer for any future scale. It is the choice that matches the system we actually have today: closely related products, a small operational footprint and a desire to keep identity coherent while product data remains logically separated.
A shared account does not mean one giant shared database
“Common identity” can be misunderstood as “everything shares everything”. That would be a poor boundary. Identity answers who the person is. Product data answers what a particular application needs to know about that person. Those are different questions and should remain different in the data model and security rules.
Puzzle progress, game statistics, preferences or future product-specific information should have explicit ownership. A shared user identifier can connect experiences where that connection is useful, but it does not give every application a reason to read every collection. Designing that distinction now is valuable even before the final account experience exists.
It also keeps the roadmap honest. The architecture can permit future cross-product identity without advertising synchronisation that has not shipped. Possibility is not the same thing as a published feature.
The monorepo has to express architecture, not erase it
The repository is also moving toward clearer application boundaries. A monorepo only helps if it makes ownership easier to understand. “Everything is in one repository” is not, by itself, an architecture.
Our direction is to keep applications explicit and move genuinely shared capabilities into packages when there is enough repeated use to justify a stable contract. The Blupoli root site and Puzzles should be separately understandable applications. Shared design tokens, common utilities or cross-product contracts can live in packages when that reduces copying without creating a dependency web.
We are deliberately cautious about extracting shared code too early. Two similar files are not automatically a package. A package creates a compatibility responsibility: changing it can affect several applications. We want the repetition to prove the abstraction before we promote it.
This is the same lesson we learned inside Puzzles itself. As described in our article about puzzle-engine architecture, useful reuse comes from a real repeated boundary, not from forcing unlike mechanics through the same shape.
A monorepo should reduce coordination cost
There are three outcomes we want from the repository structure. First, a contributor or agent should be able to find where a responsibility lives without reverse-engineering the whole project. Second, a shared capability should be reusable without copy-and-paste. Third, when that capability changes, verification should make the impact visible before deployment.
Those goals matter more than the number of folders. A visually tidy tree can still hide dangerous coupling. Conversely, a temporary migration state can look messy while having very clear ownership. We prefer incremental movement because it lets us preserve working deployments while the structure catches up with the product model.
Deployment still starts with Git, but it can run on our own machine
Another part of the transition is less visible to readers: where deployment jobs execute. GitHub Actions remains the coordinator, but the actual build and Firebase CLI steps can run on a self-hosted runner on our Mini PC.
A self-hosted runner is not automatically superior to GitHub-hosted infrastructure. It introduces maintenance, availability and security responsibilities. In our case it fits an environment we already operate for development and automation, gives us control over the toolchain, and keeps the workflow familiar: changes are still triggered through the repository and still have to pass the same checks.
The architectural point is more interesting than the hardware choice. Source control, build execution, hosting target and public domain are separate layers. Once those layers are explicit, each can evolve without pretending that “the website” is one indivisible deployment object.
Domains force hidden assumptions into the open
Buying a domain is easy. Making it the authoritative public location for several evolving surfaces is where architecture becomes concrete. DNS records, registrar parking, verification records, Hosting targets and certificate provisioning all have to agree on who owns the request.
One practical example was a registrar configuration that kept automatic records while the domain used a presentation page. From the DNS editor it looked as though the old record could not be changed. The fix lived a layer higher: switch the domain to a mode where the records were actually under our control.
This is exactly the sort of detail that disappears from final documentation. “Point the domain at Firebase” is technically true and operationally incomplete. Devlog is useful because the difficult part is often discovering which system still controls a value that appears to belong somewhere else.
Published URLs are part of the product
Once a page has been indexed, shared or bookmarked, its URL is no longer an internal implementation detail. That changes how we handle editorial migration. A cleaner new route is not automatically worth breaking an established slug.
This article itself is a good example. Its historical slug remains stable even though the title has been rewritten to describe the transition more clearly. Canonicals, language alternates and redirects can communicate the current architecture without pretending the old path never existed.
The same principle applies when moving content between hosts. A successful migration is not “the HTML loads on the new domain”. Search engines and readers need an unambiguous canonical location, translations need reciprocal hreflang, old routes need deliberate redirects, and generated sitemaps need to describe the current state rather than every state the project has ever had.
SEO here is not a marketing afterthought. It is how the public architecture explains itself to machines and people.
The root homepage needed to stay small
Once Blupoli had a root site, we had an obvious temptation: fill it with cards for every direction we might someday explore. We removed that temptation from the design. A root brand page should explain what exists, not manufacture a portfolio out of placeholders.
Today it can do a small number of jobs well: establish identity, open Blupoli Puzzles, expose editorial work and present a high-level roadmap. If a new product becomes real, the page has room to grow. Until then, empty space is more honest than a grid of “coming soon” labels.
The same restraint helps brand design. Fewer competing destinations allow the logo, typography and core visual system to remain clear. The root does not have to outshine its products; it should orient people toward them.
Light and dark modes belong to the shared identity
Puzzles taught us that a theme is not just a background switch. Text hierarchy, borders, selection states and board surfaces all need semantic roles. The Blupoli root now follows the same expectation: respect the system preference when no explicit choice exists, allow the user to override it, persist that choice and keep browser chrome in sync.
This small feature exposed a real security interaction. The root page originally had a CSP with script-src 'none' because it had no JavaScript. Adding a first-party theme script made that rule too strict for the new behaviour. Rather than opening the policy widely, we changed it to permit same-origin scripts. The feature gained exactly the permission it needed and no more.
Shared identity becomes meaningful in details like this. Products do not need identical layouts, but moving between them should not feel as though the visual language and basic interaction philosophy have been discarded.
The Blog is system memory, not a marketing attachment
As the project matured, editorial publishing stopped being a decorative “news” area. Long-form posts preserve product decisions. Devlog records trade-offs. Git provides a factual sequence of changes. Together they create a history that can answer why a route, package or workflow looks the way it does months later.
That memory deserves to sit at the Blupoli level because its subjects already exceed the puzzle product. Articles about hosting, AI workflows or repository organisation are not puzzle navigation. They are part of understanding how the wider project evolves.
This also makes the relationship reciprocal: a product article can link into technical context when readers want it, while a technical story can point back to the product behaviour that motivated the work. Clear boundaries improve linking because we no longer need one navigation to carry every purpose.
The roadmap moves to the root
A root brand creates two different roadmap scales. Puzzles has detailed product and engineering work. Blupoli needs a much smaller public view: what is active, what is being consolidated and which directions are still exploratory.
We intentionally avoid turning the homepage into our internal backlog. Internal tasks can change daily. A public roadmap should remain intelligible even when implementation order moves. It communicates direction, not fake scheduling precision.
Separating the ecosystem also protects Puzzles’ speed
There is a practical performance-of-development reason for the new boundaries. Every responsibility placed inside Puzzles eventually participates in Puzzles decisions. If its navigation has to carry the Blog, brand roadmap, future products and institutional content, then changes to the wider ecosystem keep touching an application whose main job should be playing puzzles.
We want the game product to be able to redesign its lobby, progression or shell without negotiating with an unrelated future storefront. We want editorial publishing to reorganise feeds and categories without importing puzzle runtime assumptions. The root connects them, but does not make them one giant user interface.
This is architectural locality. A good boundary reduces the number of places that need to change together. It makes product teams faster even when, in our case, “team” may simply mean the same developer working in a different part of the system tomorrow.
What we are deliberately not sharing yet
There is another side to shared infrastructure: knowing what not to centralise. We are not building a universal component library for every possible future Blupoli application. We are not forcing product-specific navigation into a root package. We are not putting every data model behind one generic repository because the word “shared” sounds efficient.
Shared code has leverage only when the concept itself is shared. Visual tokens can be common because the brand needs a coherent foundation. Authentication may become common because a person should have one identity. Puzzle-state persistence remains a Puzzles concern. Editorial indexing remains a publishing concern. Those distinctions protect the ecosystem from a different failure mode: a central layer so broad that every product becomes difficult to change independently.
The hardest part of the transition was not the logo
The visual identity remained recognisable. The difficult work was deciding what the new name implied. When a project is small, brand, domain, repository, product and company can feel interchangeable. Growth exposes where they are actually different.
Separate them too late and migration becomes painful. Separate them too early and you build architecture for imaginary requirements. Our goal is to stay between those extremes. Blupoli exists because the puzzle project had already outgrown the role of being the only possible container. Future product names will become public only when there is enough reality behind them to justify the boundary.
Boundaries become especially valuable when agents are involved
There is another reason we care about making product ownership explicit: more of the implementation workflow now involves coding agents. An agent can move quickly across a repository, but speed becomes dangerous when the repository does not clearly communicate which application owns a route, which package is safe to reuse, or which public URL must remain stable.
A good boundary gives an agent a smaller problem. Work on Puzzles can focus on game runtime, catalogue and progression. Work on the root site can focus on brand and product discovery. Editorial changes can follow their own publication contract. Shared packages are visible because they have genuinely cross-application responsibilities. That structure reduces the amount of implicit context an agent has to infer correctly before making a change.
It also improves review. A diff that touches an unexpected application becomes a signal worth investigating. A deployment workflow that suddenly needs permissions outside its target is easier to question. Architecture is therefore doing more than organising humans; it is constraining automated contributors so that speed does not silently widen the blast radius.
Operational simplicity is a feature we want to preserve
It would be easy to make the new structure look more “enterprise” by giving every surface its own cloud project, deployment stack and account model. That would increase separation and also increase the number of things we have to operate. At our current scale, complexity that exists only to imitate a larger organisation is a liability.
We prefer reversible decisions. Multiple Hosting sites inside one Firebase project give us useful deployment independence today. If one product eventually needs stronger isolation, the boundary is visible enough that migration can be considered with real evidence. The same applies to the monorepo: applications can share a repository while remaining independently buildable, and they can be split later if operational reality ever justifies it.
This principle keeps the architecture anchored to the product we have rather than the company we might imagine. Blupoli should be ready to grow, but readiness means leaving clean seams and good evidence, not pre-paying every possible future infrastructure cost.
What still needs to change
The transition is not finished. Repository structure will continue to get clearer. Some workflows still carry historical assumptions. Editorial routes and their canonical metadata need to stay aligned with the public architecture. Shared services will need stronger contracts as soon as more than one mature product actually consumes them.
We will also have to keep deciding where sharing stops. A common account does not require a common database schema. A common visual language does not require identical layouts. A monorepo does not require universal packages. Good architecture is not maximising reuse; it is making the cost and ownership of reuse explicit.
The essential direction, however, is settled. Blupoli should remain a small root identity with products that can grow on their own, connected by carefully chosen shared infrastructure. Blupoli Puzzles can therefore become a better puzzle platform without carrying every future idea on its shoulders.
That is a much more meaningful change than a rename. It is an attempt to build a home that can grow without asking each new room to pretend it is the same room we built first.