A small game website can survive an astonishing amount of local decision-making. One page gets a special button. Another uses a slightly different header. A third hard-codes a dark background because that was the quickest way to make the board readable. Nothing looks catastrophic because each exception is seen in isolation.
A large puzzle catalogue changes the mathematics of those choices. The same slightly awkward control is no longer one awkward control; it appears across dozens of games. A mobile navigation flaw is no longer a problem on one route; it sits in front of every play session. A colour chosen without a semantic token becomes a light-mode regression waiting to happen in many different boards.
That is why a significant part of our recent work on Blupoli Puzzles has looked less spectacular than adding new puzzle mechanics. We have been tightening mobile navigation, responsive controls, light and dark themes, shared footers, onboarding coverage, editorial boundaries and the relationship between the Blupoli brand and the Puzzles product. None of those changes increases a catalogue counter. All of them determine whether a large catalogue still feels like one product.
Responsive does not mean “everything fits”
The weakest definition of responsive design is easy to satisfy: remove horizontal scrolling, shrink the board and call the page mobile-friendly. An interactive puzzle needs a stricter definition. The board must remain legible, touch targets must remain comfortable, controls must preserve hierarchy, and the player must be able to understand what is actionable without spending half the screen on chrome.
A board can technically fit inside a phone and still be unpleasant to use. A difficulty selector can fit but become too small for reliable tapping. A toolbar can remain visible while pushing the actual puzzle below the fold. A desktop navigation row can be squeezed until labels wrap, yet still fail as a mobile information architecture.
We started treating narrow screens as their own layout problem rather than a scaled-down desktop. Common controls now have responsive sizing rules. The product shell is more deliberate about what stays visible and what can move. The footer has a real narrow-screen layout instead of relying on accidental wrapping. These changes sound mundane, but they have a large multiplier because a shared pattern can improve many games at once.
Mobile navigation had to become a product state
A horizontal navigation bar works while there is plenty of width. It stops working when the product gains games, statistics, theme controls and other destinations. Reducing font size is not an architecture. A mobile menu needs its own state and behaviour.
That means a trigger with an understandable accessible name, a correct aria-expanded value, a way to close with Escape, sensible behaviour when the user clicks outside, and a reset when the viewport returns to desktop. It also means deciding which destinations actually belong inside Puzzles. The menu should help someone play and navigate the product, not become a catalogue of every piece of Blupoli.
This is one of the patterns that changed our definition of “shared UI”. A reusable component is not merely markup that looks the same. It is a behavioural contract. Once that contract is right, every game benefits from it without each engine having to relearn how a menu should work.
Control size was platform debt
Several puzzle screens inherited buttons and selectors from earlier iterations of the shell. They were acceptable on a desktop pointer and increasingly poor on tablets and phones. Fixing them game by game would have produced dozens of slightly different answers.
Instead, control sizing moved into shared responsive rules. New game, undo, hint, size and difficulty controls can keep a coherent visual weight and a reasonable touch area while individual engines still add the actions they genuinely need. The change is simple in code and substantial in use: fewer tiny targets, less accidental tapping and less visual noise.
It also forces prioritisation. A small screen is brutally honest about which actions deserve permanent space. If every possible operation is treated as primary, the toolbar becomes the product. Responsive design therefore becomes an information-design exercise as much as a CSS exercise.
The footer is part of the system too
Footers are easy to postpone because they appear after the “important” content. In a multi-surface product they have a real job: they close the information architecture, expose stable destinations and reinforce where the user currently is. A shared responsive footer also helps the wider Blupoli structure feel connected without forcing every surface to use the exact same navigation.
This matters as Puzzles and the editorial site become clearer product boundaries. Puzzles can remain focused on playing while still offering a way back to Blupoli. The Blog can do the opposite: prioritise reading while keeping the product one deliberate click away. Consistency is not identical chrome; it is a predictable relationship between places.
Light mode became an accidental architecture audit
Dark-first interfaces make it very easy to hide design debt. A developer chooses a grey that looks fine on one dark surface, a translucent border that happens to work against black, or a selected state whose contrast depends on the background never changing. Everything appears stable until a light theme arrives.
Then assumptions become visible. Secondary text fades away. Borders disappear. A selected cell no longer looks selected. A custom board keeps a dark local background while the surrounding shell changes. The problem is not “light mode needs more colours”; it is that visual meaning was encoded in raw values rather than semantic roles.
We therefore treat themes as tokens and states. User choice is persisted. In the absence of an explicit preference, the system setting can be respected. The browser theme colour follows the active theme. The selector communicates the action available rather than just displaying a decorative icon. Most importantly, shared components should use semantic surfaces, text colours and borders instead of assuming a particular luminance.
A security policy can expose architectural assumptions
Adding the theme control to the Blupoli root site produced a useful little lesson. The first version of the page was static and its Content Security Policy used script-src 'none'. That was an excellent rule for a page that executed no JavaScript. The moment we introduced a small first-party theme script, the browser quite correctly blocked it.
The tempting shortcut would have been to relax the policy broadly. Instead we changed only what the new capability required: first-party scripts from the same origin. This is a tiny example of a wider principle. When a feature collides with a security constraint, we should understand the permission boundary rather than remove the constraint out of convenience.
Separating Puzzles from editorial content also improves UX
Early in the project, product and development story were almost the same thing. Keeping the Journal close to the puzzle catalogue made sense. As Blupoli grew, the editorial surface started covering architecture, AI-assisted development, Firebase, domains, Android, design and publishing. Requiring someone to enter the puzzle product in order to read those stories became conceptually backwards.
So the product navigation has been getting narrower while the Blupoli root gives editorial content a more natural home. This is not separation for its own sake. It removes choices from the play context. When someone is halfway through a puzzle, the primary destinations should relate to games, progress and product functions, not the complete publishing structure of the wider brand.
The same boundary makes both sides easier to evolve. Puzzles can change its shell without dragging editorial navigation with it. The Blog can change categories, feeds or article layouts without pretending those are game-product concerns.
The root homepage should not compete with the product
Once Blupoli had a root site of its own, the obvious temptation was to build a portal with cards for everything we might create one day. We deliberately moved in the opposite direction. A brand homepage should describe what exists, not decorate itself with hypothetical products.
That leaves a simpler job: identify Blupoli, provide a clear entrance to Blupoli Puzzles, expose editorial work and show a high-level roadmap. Empty space is not a failure to fill a grid. It gives current products enough room to be understood and leaves future expansion available when there is something real to add.
A public roadmap is not our backlog
We also had to separate the idea of a public roadmap from the internal task list. A backlog is operational. It contains small pieces, experiments, debt and work that may be reprioritised tomorrow. Publishing it directly would create noise and accidental promises.
The public roadmap instead communicates direction: what is active, what is next and what remains exploratory. At this stage most of that direction naturally concerns Puzzles because it is the mature product. We can talk about catalogue depth, shared platform work, account foundations or possible Android surfaces without inventing dates that the repository cannot support.
This distinction matters for trust. A roadmap should remain understandable even when individual implementation tasks move. It describes intent, not a schedule disguised as certainty.
A large catalogue needs an interface budget
Catalogue growth creates a cost that does not show up in bundle size: attention. Every selector, helper, banner and secondary action competes for a limited amount of cognitive space. On one page, adding one more visible control is easy to justify. Across dozens of games, repeating that instinct produces toolbars that look like administration panels.
We have started treating the visible interface as if it had a budget. Every permanent control needs a reason to occupy attention in that context. That budget differs by puzzle. Sudoku may need candidates and erase. A connection puzzle needs a different input language. A game against a CPU has turn-related controls that a pure logic puzzle does not have.
The shared layer therefore does not dictate every button. It defines hierarchy, spacing, touch size and behaviour. Individual engines spend the budget on the actions that make their mechanic understandable. This is especially useful on mobile, where the constraint forces us to discover priorities that usually improve the desktop layout as well.
The source of truth prevents the platform from lying about itself
Large catalogues create another temptation: hard-code facts that look stable. “There are the announced catalogue” can be true on the publication date of this article and false soon afterwards. “This game is available” can change during an audit. If the same number or state is copied into the homepage, articles, navigation and generated pages, the site eventually contradicts itself.
We therefore derive more current information from structured sources in the repository: game manifests, taxonomy, release status and site configuration. Editorial prose can still preserve a number when it is explicitly historical. This article is a snapshot of a phase in September 2026, so discussing the scale that triggered the work is meaningful. The live interface, however, should not depend on the same frozen sentence.
The distinction between a dated fact and a current state is small but essential. It also applies to routes, locales and brand naming. The more surfaces we operate, the more valuable it becomes to let the build pipeline normalise shared facts instead of teaching every page its own version of reality.
Consistency is measurable without making every puzzle a clone
“Consistency” can be misread as “make every screen identical”. That would be the wrong outcome for a puzzle platform. We want consistency in things a player learns once and expects to find again: where global actions live, how difficulty changes, how a disabled state behaves, how victory is communicated, how focus moves and how large a touch target must be.
The puzzle board itself needs freedom. Geometry, semantic colours, gestures and the representation of constraints belong to the mechanic. An Akari board should not be disguised as Sudoku to satisfy a component abstraction. Blupoli provides the recognisable frame; the puzzle provides its own visual language.
This is the same boundary described in our article on puzzle-engine architecture and in the piece about a shared UI for games that do not look alike. Reuse is valuable when it removes repeated product decisions, not when it erases the mechanic.
Onboarding benefits from the same stability
As the shell becomes more predictable, onboarding can spend less time explaining the shell. If undo, size selection, difficulty and global controls move around from game to game, every tutorial has to begin by teaching the application again. A stable shell lets the first-run experience focus on what is actually new: the puzzle’s reasoning pattern.
Our onboarding work therefore uses mechanic profiles and explicit mappings rather than assuming one generic tutorial can explain everything. Repository checks can also verify coverage so that publishing a game without a teaching path becomes visible before release. This is a good example of turning a UX expectation into an engineering contract.
The Blog and Devlog give the platform memory
Shared components solve repeated code. Editorial memory solves repeated decisions. The Blog records product stories that deserve longer explanation. Devlog captures architecture and development choices. Git provides a factual history of what changed. Together they make it possible to understand why the current structure exists instead of treating every odd-looking rule as arbitrary legacy.
That memory is useful to readers, but it is also useful internally. Months later, the reason a route is stable or a control behaves differently in one mechanic can be reconstructed without relying entirely on personal recall. As the project gets larger, written context becomes another form of infrastructure.
Transversal improvements are less visible and more profitable
A new puzzle produces an obvious screenshot and a simple announcement. A better breakpoint, CSP rule or focus behaviour is harder to showcase. Yet once the catalogue is large, the latter often has more leverage. Fixing one shell component can improve every playable route. Adding one CI rule can prevent the same omission from reaching dozens of future games.
This changes how we measure progress. Early on, growth was visible mostly as new cards. Mature platform work is increasingly about how much repeated work we can remove and how many guarantees can be made once instead of rediscovered per game.
What “stable platform” means to us
There is no day when the platform becomes finished forever. We can still define useful signs of maturity. A transversal change should require very few game-specific patches. A new engine should integrate without copying an entire page. A theme change should not require hunting raw colours through dozens of files. An editorial route should be movable without breaking the play product. An accessibility improvement in a shared control should propagate wherever that control is used.
Checks also need to be able to contradict us. Visual review is necessary but cannot guarantee onboarding coverage, locale-correct links or release metadata across a large catalogue. Repeated expectations should become validation where possible. That reduces the amount of product knowledge that lives only in someone’s head.
This is why platform work can look slower from the outside while making everything that follows faster. Every explicit contract removes a repeated decision. Every shared component absorbs a future improvement. Every structured source of truth replaces a fact that would otherwise go stale.
Platform work also needs a regression budget
Shared components have leverage, but leverage cuts both ways. A local bug affects one game; a bug in the shell can affect the whole catalogue. That means platform changes deserve a different review habit. We cannot treat a navigation refactor or control-sizing change as safer merely because it contains less game logic. Its blast radius is larger.
Our practical answer is to combine broad automated checks with a small set of representative manual routes. We want tests to catch structural failures — missing assets, broken routes, invalid metadata, untranslated interface keys, unsupported variants — while manual review samples the places automation is weakest: real touch density, visual hierarchy, theme contrast and whether the board still has enough room to think.
This also changes how we introduce shared abstractions. A component that is used by forty games should not acquire a game-specific option casually. Each flag is a potential branch every consumer has to live with. When one mechanic genuinely needs different behaviour, it can be healthier to expose a narrow extension point than to turn the common component into a switchboard of historical exceptions.
The reward is compounding confidence. Once the shared layer becomes both expressive and well checked, future games inherit more than CSS. They inherit solved interaction problems, known accessibility behaviour, localisation plumbing and publication rules. That is the real platform dividend: not only writing less code, but having fewer categories of problem to solve again.
Performance includes decision latency, not only load time
We normally talk about web performance in milliseconds, bytes and rendering work. An interactive catalogue has another form of latency: how long it takes a person to understand what to do. A fast page with crowded controls can feel slower than a slightly heavier page whose hierarchy is obvious.
This is why we treat navigation, labels, grouping and onboarding as performance work in the broad product sense. Reducing one unnecessary choice can be more valuable than shaving a small amount from an already-fast interaction. Clear defaults, stable placement and predictable feedback shorten the path from “I opened this puzzle” to “I am thinking about the puzzle”.
That is ultimately what the platform is for. The shell should disappear quickly enough that attention reaches the mechanic. Every shared decision we make should be judged against that goal: does it help the player get to the interesting reasoning sooner, or has the platform started demanding attention for itself?
A usable platform is one that can keep growing without getting heavier
The goal is not to declare the website “done”. It is to make the next change cheaper rather than more expensive. If adding a product forces us to rebuild the root site, the boundary is wrong. If adding a theme requires editing a hundred colours manually, the visual architecture is wrong. If every new puzzle needs its own mobile menu, the shell is wrong.
Responsive design, themes, navigation, roadmap and editorial separation look like different tasks because they live in different files. They are all answers to the same question: how can a large system retain clarity while it changes?
Our current answer is deliberately simple to say and difficult to execute: share behaviour where the player benefits, keep product boundaries explicit, derive current facts from sources of truth, and let each mechanic preserve the identity it needs.
That is what turns a collection of puzzle pages into a platform. The important number is not the catalogue count. It is the amount of the system we can improve once and trust everywhere else.