Some redesigns begin because a page looks dated. This one did not. The Blupoli home had a more subtle problem: it could look perfectly respectable while describing the wrong product model. The page had been shaped when the project was much closer to “a large puzzle collection with some writing around it.” Since then, we had separated Blupoli from Blupoli Puzzles, turned Blog and Devlog into distinct editorial surfaces, built shared brand infrastructure, unified language and theme behavior, clarified the monorepo boundaries, and made an explicit decision that Blupoli should be able to host more than one product. The home page was still carrying the hierarchy of the earlier phase.
That mismatch matters because a home page is more than a stack of sections. It answers the first question a new visitor has: “what is this?”. If the answer is “Puzzles, plus a blog,” every future product has to fight an expectation established at the front door. If the answer is “a place where we publish digital products and document the work behind them,” then Puzzles can remain the most visible thing we have today without becoming the conceptual limit of the brand. The redesign started with that distinction. We were not trying to decorate the same story. We were trying to tell the correct one.
The starting point: a home page that still belonged to the previous phase
The old home was not a bad page. In fact, several rounds of work had already improved it substantially. It had responsive navigation, dark and light themes, localized content, a clearer relationship between Blupoli and Puzzles, and links into the editorial side of the project. The problem was the ordering of ideas. The page was still organized around two primary doors: play and read. Copy such as “Two ways in” and “Puzzles is the current focus” had been accurate when it was written, but it gradually became a hard-coded product hierarchy.
The contradiction became more visible because the rest of the repository was moving in the opposite direction. The Blupoli Puzzles-to-Blupoli migration had established a broader public identity. Shared UI started to connect the main site and Puzzles. Blog and Devlog stopped behaving like extra links hanging off a game site. We had invested in platform infrastructure, yet the most visible page still explained the platform through its first product. Nothing crashed. No test failed. It was an information-architecture bug.
The audit gave us a deliberately simple target: blupoli.com should feel like the home of Blupoli products, not like a Puzzles landing page with a blog attached. That sentence became the filter for the implementation. Sections that reinforced the platform stayed. Sections that existed mainly to explain Puzzles as though it were the whole of Blupoli had to change.
Redesigning the hierarchy instead of adding another section
The easiest implementation would have been to keep the page and add a “Products” block somewhere below the hero. That would have satisfied a checklist, but the page would still have said that Puzzles is the real center and “Products” is a new idea added afterwards. We therefore changed the hierarchy from the first screen. The hero now speaks about digital products, experiments and the work behind them. Its primary action invites the visitor to explore Blupoli itself. Puzzles remains highly visible, but as a concrete product destination rather than the definition of the platform.
We also reduced the hero’s vertical footprint. A platform home should not spend the entire first viewport explaining an abstract promise. The first real product needs to appear quickly, so the relationship between platform and products is visible without a long scroll. The hero still has personality, but it hands control to the product catalogue much sooner.
The next step was to stop mixing conceptual categories. Puzzles belongs to Products. Blog and Devlog belong to the editorial activity layer. Experiments are a type of work the platform may host, not imaginary products that need fake cards today. Current priorities belong in a concise “Now” section, while detailed implementation belongs in the Devlog. These distinctions sound editorial, but they are architectural: each layer can now evolve without forcing the home page to pretend everything is the same kind of thing.
The home page stops organizing Blupoli around one destination and starts organizing the experience by responsibility.
The hero became a map of the ecosystem
The visual side of the hero changed purpose too. Instead of acting as an illustration of the current game product, it now represents the ecosystem. Blupoli sits in the center. Around it are Blupoli Puzzles, Blog, Devlog and an unnamed future node. The unnamed part matters. We wanted to communicate that the architecture can grow without inventing a product simply to make the composition look more complete.
The future node does not say what we will build. It only says the structure has room for more products. That difference between capability and roadmap is something we tried to preserve throughout the redesign. A credible platform does not need to fill empty spaces with fictional inventory. It can be explicit about being small today while still showing that its structure is not hard-wired to a single product.
The ecosystem map also doubles as navigation. Puzzles, Blog and Devlog are real destinations rather than decorative labels. The visual therefore explains the architecture while letting visitors move through it. That is a stronger use of the hero than a generic illustration beside a paragraph of positioning copy.
A product registry replaces a promise written directly into HTML
The most important technical change in the Products section is not the card design. It is content/products.json. Until now, presenting Puzzles on the home page could be solved by writing the card directly into the HTML. That is perfectly reasonable while there is one product, but it creates a future trap: presentation and product inventory become the same thing. Adding another product means editing the page structure, reproducing fields manually, remembering localization, and deciding again what a product card needs to know.
PR #108 introduces a canonical product registry. Today it contains exactly one item: Blupoli Puzzles. The record declares identity, kind, publication status, localized URL, translation key, platform and a small set of preview items. The home builds its Products section from that source. There is no fake second application, no unnamed beta disguised as a real product, and no inflated catalogue intended to make Blupoli look larger than it is.
The benefit becomes clearer when we imagine the next real product. The question is no longer “how do we copy the Puzzles card?”. It becomes “what information does a product need to declare in order to join Blupoli?”. That is a much better boundary. The home becomes a renderer of product data rather than an accidental product database.
The build also requires at least one product to exist. This is a small but meaningful guard: if the registry breaks, the site cannot quietly ship an empty Products section. The platform now depends on a canonical source and the build acknowledges that dependency.
Recent activity now comes from the editorial system instead of another hand-maintained list
A static home page tends to drift fastest in its “latest” content. Blog and Devlog already have their own editorial pipeline, so copying three recent links into the home would create a second list that someone has to remember to update. The new Latest section reads from editorial-manifest.json, the same editorial source that already knows about published stories and development notes.
This changes both maintenance and the way the site feels. The home no longer needs a content edit every time we publish something. Recent activity becomes an output of the editorial pipeline. The home behaves like a live index into the project rather than a manually refreshed brochure.
It also reinforces a product decision. Blog and Devlog are not footer utilities. They are part of what Blupoli is. Blog can carry longer editorial stories, guides and broader explanations. Devlog can focus on implementation, trade-offs and the evolution of the product. The home exposes both as active areas without pretending they are products in the same sense as Puzzles.
The detailed roadmap left the front page
One of the most useful changes was removing the long roadmap that occupied a large portion of the old home. The roadmap still matters; it was simply solving the wrong problem in the wrong place. A platform home needs to explain identity, products and current activity. Detailed future work belongs in an editorial surface that can change pace without making the home page look like a project board.
We replaced it with a compact “Now” section. It describes three verifiable directions: continue polishing Blupoli Puzzles, strengthen the shared Blupoli foundation, and document the real work. Each item is a direction rather than a date promise. Visitors who want detail can follow the Devlog.
This removes noise and avoids a common failure mode: presenting plans as though they were features. The home says what Blupoli is and what the project is working on now. Devlog can carry the uncertainty, implementation detail and changing priorities. Giving those jobs different surfaces makes both more honest.
The redesign forced us to finish the shared visual foundation
While working through the home, another piece of debt became impossible to ignore. Brand colors still appeared across surfaces as duplicated values or inherited variables. That was especially risky now that the main site, Puzzles, Blog and Devlog were converging visually. We could produce a polished new home and still reintroduce drift the next time someone changed a cyan or violet in one stylesheet but not another.
The solution was to make packages/ui/blupoli-design.css the canonical source for brand colors. It defines tokens such as --brand-navy, --brand-cyan, --brand-indigo, --brand-violet, --brand-mint and the primary gradient. The home, shared header, footer and other surfaces consume those tokens instead of redeclaring equivalent colors.
The regression test does more than check that the tokens exist. It also guards against old brand colors and parallel variables returning in places that should now depend on the shared layer. This is the kind of quality improvement we increasingly prefer: documentation says what should happen, while tests make accidental reversal visible.
Localization moved from phrase replacement to semantic content
The home was already available in six languages, but the previous implementation had a fragile core: locale files contained arrays of phrase replacements. That can work while a page is small and copy changes rarely. It gets harder to reason about once the hero changes, sections move, wording is reused in different contexts, or one language needs a sentence structure that does not map neatly to the source phrase.
The redesign converts apps/web/home-i18n.json to semantic keys. Each locale now exposes structured data such as seo.title, hero.lead, products.puzzles.summary, latest.title, about.title and now.title. The template consumes those keys directly. Translation no longer depends on a source sentence remaining character-for-character identical.
This also improves content modeling. “Open product” and “Play Puzzles” are not the same string just because both can be buttons. They represent different actions and may need different wording in another language. Semantic keys preserve that distinction rather than reusing text for convenience.
The home test iterates through EN, ES, IT, PT, FR and DE and requires all of the major sections to exist. It also verifies that the old replacements mechanism is gone. The build rejects unresolved placeholders and checks that localized pages link to the matching Puzzles locale. Internationalization becomes a structural property of the page instead of a cleanup pass after the layout is complete.
Navigation and footer had to accept the new hierarchy too
A page cannot convincingly call itself a platform while its shared navigation is still arranged around one product. PR #108 reorganizes the shared chrome around Products, Blog, Devlog, About and Puzzles. Puzzles remains a strong call to action because it is the product people can use today, but it no longer consumes the entire information architecture.
This work builds directly on the shared UI architecture we documented in One interface, two applications. We had already extracted common identity, navigation, language and theme behavior instead of duplicating the header across the main site and Puzzles. The home redesign benefits from that foundation: changing the global hierarchy can propagate through shared components instead of becoming a new fork.
It also creates a more stable growth path. If a second product appears later, it should not require inventing another special navigation model just to make it visible. The global structure already has a concept of Products and a specific entry point for Puzzles. New inventory can grow inside the first without forcing the second to become the umbrella.
Analytics measures destinations without taking over the interface
A platform home has one question a single-product landing page does not need to ask as explicitly: which destination do people actually choose? To observe that without scattering tracking calls throughout the implementation, we added data-analytics-* attributes to the main interactions. The canonical event is home_destination_click, with destination and location values that distinguish the hero, ecosystem map and other sections.
The markup relies on the observability layer that already exists and follows the project’s consent-aware analytics behavior. The home declares intent rather than embedding vendor-specific tracking logic in each card. That keeps product UI and measurement infrastructure separate.
We are deliberately not using analytics as retroactive justification for the redesign. There are no post-launch numbers yet, so we make no claims about conversion, engagement or time on site. The instrumentation exists so we can observe the new hierarchy after it is actually published. Until then, the redesign is justified by product clarity and architecture, not by invented performance gains.
The build now knows what a regression in the home looks like
One of the most important outcomes is that the redesign is not just a set of styles. scripts/build-web.mjs now contains home-specific regression rules. The build fails if no product is generated, if the key platform sections disappear, if semantic placeholders remain unresolved, if legacy copy such as “Two ways in” or “Puzzles is the current focus” comes back, or if a localized page points to the wrong Puzzles locale.
test/home-platform.test.mjs adds another layer. It validates the product registry, checks semantic localization across all published locales, confirms the presence of Products, Latest and About structures, and verifies that brand colors have one canonical source. These are product-architecture tests rather than pixel tests. They do not care whether a gap is 28 or 32 pixels. They care whether the home is still modeled as a platform.
That distinction is intentional. Visual regression testing can be useful elsewhere, but the decisions most likely to be accidentally reversed here are conceptual. Someone can refactor HTML, look at the result, decide it “looks fine,” and unknowingly make Puzzles the identity of Blupoli again. The gate makes that class of regression observable.
Canonical data, semantic templates, localization and build gates form a chain that prevents the front page from drifting back toward hand-maintained copies.
The home redesign only works because the surrounding platform work is already real
The home is the most visible change in this phase, but it would be misleading to describe it as an isolated design exercise. In the days leading into PR #108, several layers matured enough to make the new front page more than a standalone mock-up. The Blupoli Puzzles-to-Blupoli migration established a consistent public identity and added checks against active legacy branding. The logo became a shared asset. Header, footer and the language selector moved into common platform UI.
Theme and locale preferences were unified across Blupoli surfaces as well. That matters because a home page can route visitors into Puzzles, Blog and Devlog only if those transitions feel like movement within one family rather than jumps between unrelated sites. Editorial styling was brought onto the same token foundation, so Blog and Devlog can participate in the brand system rather than carrying a private palette. The work described in our shared UI system Devlog and the split between Blog and Devlog is direct technical context for this redesign.
Puzzles has also continued maturing as an independent product. The catalogue distinguishes playable titles from coming-soon ones, localization of game data became more structural, and visual-parity checks protect game rendering across locales. That separation is important. A platform only benefits from clearer product boundaries if the first product actually has its own state, navigation and rules. The new home can present Puzzles as a product because Puzzles increasingly behaves like one.
What changes for a visitor
From the outside, the main improvement should be comprehension. A visitor no longer has to infer whether Blupoli is a puzzle site, a personal blog or a corporate placeholder. The hero explains the platform. The next section shows the product that exists today. Recent editorial activity adds context without being buried in navigation. Another section explicitly explains that Blupoli can contain products, experiments and work documented in public.
The flow also avoids overpromising. We do not claim to have an application suite. We do not display products that do not exist. We do not label an idea as “beta” just to fill a card. Blupoli Puzzles is the only available product and the page says so clearly. Everything else communicates structural capacity rather than fictional inventory.
Navigation becomes easier to understand as a result. If someone wants to play, Puzzles remains one click away. If they want to understand how the project is built, Devlog is a first-class destination. If they want longer stories and guides, Blog has its own place. If they simply want to understand what Blupoli is, the home no longer asks them to decode a collection of inherited sections.
What changes for maintainers
The biggest maintenance win is that several decisions no longer live in page HTML as one-off implementation details. Products are declared in a data source. Recent activity comes from the editorial system. Brand colors come from the shared design foundation. Translations use semantic keys. Header and footer share the global hierarchy. Analytics events are declared through attributes. The build understands concrete invariants that define the page.
That reduces the number of places we need to remember when something changes. A new product should not require editing six static blocks. A palette adjustment should not mean hunting down duplicate hex values. A new hero sentence should not break phrase-replacement localization. A new locale should not be publishable without all major sections. None of those problems disappear entirely, but each now has a clearer owner.
Reviewing changes becomes more precise too. Instead of asking only “does the page look good?”, we can ask whether the product is in the canonical registry, whether the home renders it, whether every locale has the required keys, whether unresolved placeholders fail the build, whether design consumes shared tokens, and whether global navigation still describes the platform we intend to have. Quality becomes easier to inspect.
What we deliberately did not build
Several things were intentionally left out. We did not invent names for future products. We did not add a Blupoli account to the home as though it already existed. We did not turn the “more products” node into a public roadmap. We did not make a fixed game count a central platform claim, because that number changes and belongs to Puzzles rather than to the identity of Blupoli as a whole.
We also resisted designing a huge product schema in advance. content/products.json is small because the current problem is small. It contains enough information to render Puzzles and establish the first contract. When a second real product arrives, we will have evidence about whether the model needs more fields, new states or grouping rules. Designing twenty hypothetical properties now would be another form of coupling.
Finally, we did not rename every legacy technical file simply for aesthetic purity. Some internal routes and compatibility names still exist because they are part of a working publication pipeline. As with the editorial migration, public identity can move forward without forcing unrelated breakage into the same pull request. The rule is not “delete history”; it is “do not let legacy implementation names dictate new product decisions.”
Validation: what we know and what we cannot claim yet
At the time of writing, the redesign lives in PR #108 on feat/home-platform-redesign. The pull request is open and GitHub reports it as mergeable. That status matters in a Devlog because “implemented on a reviewable branch” is not the same statement as “deployed to production.” Everything described here is grounded in the actual branch: source files, the audit, tests, build rules and data structures. We are not claiming every visitor to blupoli.com is already seeing this version.
Source-level validation includes test/home-platform.test.mjs, covering the product registry, semantic localization for all six locales, canonical brand tokens and derivation of home content from the correct sources. The build adds its own failure conditions. The audit in docs/audits/blupoli-home-platform.md records the implemented changes and the regression rules the redesign is supposed to preserve.
What we do not have yet is post-deployment behavioral evidence. The primary clicks are instrumented, but there is no basis for claiming the new home improves conversion, session length or any other product metric. Nor does “mergeable” mean “proven across every browser and device.” Visual review and production observation remain part of the work after integration.
The lesson: a home page can be architecture
The most useful lesson from this work is that a home page is not only marketing. In a platform that expects to grow, the home encodes boundaries. It decides what counts as brand, product, editorial content, current work and future possibility. If those categories are blurred, the implementation starts reflecting the same confusion: hard-coded cards, replacement-based translations, duplicate colors, manual links and roadmaps that read like features.
Once we separated the responsibilities, visual design and software architecture started reinforcing each other. The product registry exists because Products is a real concept. The editorial manifest feeds Latest because Blog and Devlog are their own layer. Semantic translation keys exist because the home has stable content structure. Shared tokens exist because multiple Blupoli surfaces should feel like one family. Build gates exist because some decisions are too important to rely on somebody remembering a document.
This continues the lesson we learned when the Puzzles catalogue grew beyond seventy games. In the catalogue redesign for 71+ games, scale broke the flat-list model and forced us to model discovery, categories and status. The scale we are preparing for now is different: not more games inside Puzzles, but more kinds of things inside Blupoli. The underlying answer is similar. If a structure is expected to grow, it is worth modeling before the interface becomes its accidental database.
It also continues the brand transition described in Blupoli changes its skin. Renaming the public identity was only the beginning. Giving that identity its own hierarchy, shared visual system, common navigation and a home that does not confuse platform with first product is what turns a branding change into architectural reality.
What comes after this home page
The redesign establishes a foundation rather than a permanent final state. Once the pull request is integrated, we still need to observe real behavior, inspect the composition across screen sizes, and verify that localized routes and cross-surface destinations behave as expected in production. If consent-aware analytics eventually provides enough data, we can examine which destinations people choose and where friction exists. That evidence can justify later changes; we do not need to pre-invent them now.
We also need to keep the product registry disciplined. A canonical source stops being useful if exceptions start creeping back into the template. The same is true of the visual system: centralizing brand colors only works if new surfaces consume tokens rather than creating private palettes. Semantic i18n only remains semantic if future sections add keys instead of reintroducing text replacement as a shortcut.
The real test will come when Blupoli has a second product to publish. That is when we will learn whether the current product contract is general enough or needs to evolve. Until then, keeping it small, explicit and backed by a real product is the safer architecture.
From a page that described the present to one that can grow with the project
The result of this phase is not merely “a nicer home page,” even though the visual difference is substantial. It is a front page that represents the system we are actually building. Blupoli sits at the center as a platform. Blupoli Puzzles is the first available product. Blog and Devlog expose activity and context. Experiments have a conceptual place without being misrepresented as finished products. Current work is summarized without turning the home into a backlog. Behind that hierarchy are data sources, structured localization, shared tokens, observability and tests designed to keep it intact.
That kind of redesign is less dramatic than a complete rewrite and more useful. It does not change frameworks, replace the repository or discard previous work. It takes advantage of the layers we have already built and corrects the part of the product that was still telling an older story. The home stops being a storefront centered on the first product and becomes the index of a platform that is still small but already understands how it wants to grow.
That may be the clearest sign of maturity in this phase. Blupoli does not need a crowded catalogue of products to look like a platform. It needs the few things that exist to have clear boundaries, a coherent identity and an architecture capable of accepting the next thing without breaking the previous ones. The home redesign is the visible expression of that idea.