Projects that eventually grow large rarely begin with their future shape neatly drawn. More often they start with a specific irritation or curiosity: something that should be straightforward is awkward, an existing experience never quite feels right, or a small idea proves richer than expected. That was true of the project known as PuzzleHub in August 2026 and now living inside Blupoli as Blupoli Puzzles. The original premise was not “let’s build a logic-game platform.” It was simpler: make a Sudoku that was pleasant to use in a browser, and build it in a way that did not make the next puzzle prohibitively expensive.
The naming needs a little historical context. PuzzleHub was the original product name during the project’s first phase; it is not the current brand. As the scope widened, Blupoli became the parent identity and the puzzle catalogue became Blupoli Puzzles. We keep the old name in this story because it describes decisions made at that time, but current product work, publishing and identity belong to Blupoli. The broader change is covered in the story of the move from PuzzleHub to Blupoli. Here, the interesting part is what happened before a rebrand was even imaginable.
The first problem was not really Sudoku
There are many ways to implement Sudoku. If all you want is a grid that accepts digits, the core rules are compact: represent 81 cells, fix the clues, and make sure rows, columns and boxes obey the constraints. A usable puzzle, however, asks for much more. Selection needs to feel obvious. Notes need to be quick. Errors need to be understandable. The board must survive mouse, keyboard and touch. It needs to fit on a phone, reset cleanly, know when it is complete and avoid making the interface itself part of the challenge.
Once those details matter, a useful distinction appears. Some behaviour is specific to Sudoku: valid candidates, box structure, solution constraints. Other behaviour belongs to the product around it: how a board is rendered, how a session is preserved, how focus moves, how a new game is started, how feedback is expressed and how the layout adapts. If those responsibilities are intertwined, every future game inherits a copy of the same surrounding code and slowly develops its own slightly different version of the same experience.
The question that changed the project: what about game number two?
A simple way to test whether a first implementation is a foundation or just a prototype is to imagine the second case. The first game can get away with custom names, one-off assumptions and rules baked directly into presentation. The second forces a distinction between what is essential and what merely happened to be true in the first example. If adding another puzzle means cloning an entire page and replacing pieces until it looks different, the system is not really scaling. It is accumulating parallel versions of itself.
So the productive question became: what would have to exist for the second game to reuse the quality of the first without inheriting its rules? That led to a separation between state, game engine and presentation. The engine would understand the puzzle. The UI would understand player actions and the presentation of state. Product metadata would describe the title, route, family, instructions and other catalogue information. None of this appeared as a perfect architecture in one step. Each boundary became clearer because a new requirement exposed where the previous responsibility had been placed badly.
From game page to reusable engine
“Engine” can sound grander than the idea needs to be. In this context it simply means that a puzzle’s rules live in a unit with a clear job: create or receive a state, accept meaningful actions, produce the next state, check conditions and expose enough information for something else to render the result. The engine does not need to know where the “new game” button sits, which font the site uses or how a selected cell glows. The less it knows about those concerns, the easier it is to test, reason about and reuse.
That framing changed how new puzzles were approached. Instead of asking how to build an entire new page, the useful questions became more specific: what is genuinely unique about this puzzle’s topology, constraints, legal actions, completion state and feedback? Everything else could at least be considered for the shared experience. We later explored the idea in depth in the article about puzzle-engine architecture, but its origin is here: an attempt to stop the second game from forcing a rewrite of the first one.
A catalogue is a different problem from a folder of pages
With one or two games, a list of links can look like a catalogue. As the collection grows, discovery becomes a product problem of its own. Players need to understand what is available, distinguish kinds of reasoning, recognise familiar variants, return to favourites and find something new without facing a wall of nearly identical cards. That requirement was not part of the first Sudoku, yet it appeared long before the project could honestly be described as a large library.
Metadata therefore stopped being decorative. A name, slug, family, description, control model, difficulty signal or availability state becomes operational when it drives listings, navigation, search, editorial pages and build processes. Adding a puzzle is no longer only “put a page online.” It is registering something in a system that needs to know where it lives, how it should be presented and what it is related to. That catalogue mindset remains important in Blupoli Puzzles because it prevents growth from depending on somebody remembering every manual place that needs an update.
Shared UI should not erase a puzzle’s personality
Reuse does not mean making every puzzle look and behave identically. Sudoku needs candidates and a grid with box structure. Nonograms rely on row and column clues and different cell states. Connection puzzles may revolve around lines, nodes or regions. Other games need dragging, marking or relationships between objects. A platform that is too rigid eventually starts fighting the very games it is meant to host. The job was to share what was truly common without making variety feel like a series of awkward exceptions.
That gradually became a design rule: consistency in navigation, global controls, visual hierarchy, accessibility and product states; freedom in the surface where the reasoning actually happens. A player should feel that they are still inside Blupoli Puzzles even when the board changes completely, while each game remains free to express the interaction that makes it distinctive. The split between a recognisable frame and a specialised thinking surface is one reason a diverse catalogue can feel coherent without turning into a factory of reskinned clones.
Puzzle generation introduced a different kind of complexity
Solving a puzzle and generating one are not the same problem. The first Sudoku can be loaded from a known instance, but a platform eventually needs to ask where fresh challenges come from, how their validity is checked, and how to avoid serving puzzles that are trivial, ambiguous or structurally poor. That distinction encouraged another useful separation: code that understands rules does not automatically have to be the code that constructs instances, and neither role replaces a quality-validation step.
This grew important enough to deserve a later article, “Generating a puzzle is not the same as solving it”. At the beginning it was simply a practical consequence of wanting more than one board and more than one game. Drawing a legal grid was not enough. The platform needed a dependable supply of challenges that respected the rules and were worth a person’s time. That is where a broader idea of quality started to emerge: a puzzle can be technically valid and still be a poor experience.
Mobile screens revealed which decisions belonged to the product
Desktop interfaces can hide weak assumptions. There is space, a precise pointer and usually a full keyboard. A phone exposes the problems immediately: tap targets are too small, side panels consume the board, controls sit far from the thumb, explanatory text competes with the puzzle, and hover-only feedback disappears. Designing for narrow screens made it impossible to treat each game as an isolated collection of styles. The playing experience had to be considered as a system.
That strengthened the case for shared components and interaction rules. If every puzzle independently decided spacing, restart behaviour, help presentation, focus handling or full-screen controls, inconsistency would grow at the same rate as the catalogue. Put those decisions in the right layer and one accessibility fix or touch improvement can benefit multiple games at once. That ability to propagate improvements is less visible than “we can add a new puzzle faster,” but over time it is one of the strongest arguments for a platform architecture.
A growing library changes what “finished” means
In a one-game project, “the rules work” can feel close to completion. In a platform, the bar rises. A puzzle is not really done when its engine accepts moves and recognises a solution. It has to enter correctly from the catalogue, behave on different screen sizes, coexist with the visual theme, explain itself without an external manual, handle restarting and persistence as appropriate, keep controls accessible and avoid breaking expectations created by the games around it. The product becomes part of the context of every individual game.
That transition happened gradually but changed the work. Checks stopped being only “is the rule implemented correctly?” and began to include “does this experience belong in the whole?” Later, catalogue growth forced those expectations to become more explicit. The story of turning a large catalogue into a usable platform follows directly from the first insight: scaling content is only worthwhile when the quality of the environment around that content can scale with it.
Speed began to depend more on decisions than on typing code
A reusable base makes development faster, but not because it magically writes games. It is faster because fewer peripheral decisions need to be made again. A new puzzle does not have to reinvent page structure, metadata placement, navigation integration or the basic interaction shell. Effort can move toward what actually distinguishes the game. Reducing that surrounding work is what turns a prototype into something that can support a sustainable stream of additions.
There is a reverse effect too: the wrong abstraction spreads cost. If a shared component remains secretly coupled to the first example, every later game adds flags, branches and exceptions. For that reason, growth did not mean generalising everything immediately. Some decisions were deliberately postponed until two or three examples revealed the real pattern. That discipline is less dramatic than designing a grand architecture upfront, but it is much better at separating a recurring need from an accident of the first prototype.
AI became an accelerator, not a replacement for structure
As the project expanded, AI tools became increasingly useful for implementation, review, documentation and exploration. That could have encouraged a bad direction: produce many pieces quickly without strengthening the system that must contain them. In practice the opposite proved more useful. The more code a tool can generate, the more valuable clear contracts, canonical sources and automated checks become. Speed without structure merely creates a larger amount of work whose correctness is difficult to judge.
We describe that collaboration in the article on using AI as part of the development team. Its connection to the origin of Blupoli Puzzles is direct. An agent can help implement an engine or repeat an integration, but it performs far better when the repository makes expectations explicit. AI can remove friction from repeatable work; it cannot decide by itself which capability deserves to be shared, what quality means for the product or which trade-off is worth making.
The PuzzleHub name worked while the world was only puzzles
During the first phase, PuzzleHub described the product accurately. It was a hub for puzzles and did not pretend to be anything else. The limitation appeared when the work began to produce assets and possible directions that no longer fitted comfortably inside that name: editorial content, tooling, future products and an identity that might connect experiences beyond puzzles. The technical architecture had learned to separate game engines from the platform; eventually the brand architecture needed a similar distinction.
That is how Blupoli became the root identity and Blupoli Puzzles became the product. The decision does not erase the earlier name; it gives it a place in the story. PuzzleHub explains where the platform came from. Blupoli defines a space in which it can keep growing. That is why historical slugs such as this one remain useful while current copy avoids presenting PuzzleHub as a live brand. It is also a useful product lesson: a name can be exactly right for version one and still become too narrow when the boundary of the problem changes.
What stayed the same after the rebrand
Brands can change faster than good product questions. The question that set the project in motion—how do we make game number two avoid rebuilding game number one?—still matters. Today it can be asked at a larger scale. How can a future product share identity without being a copy? How can an editorial improvement benefit the wider site? How can common capabilities grow without taking autonomy away from each application? The shape of the system changes, but the search for healthy boundaries remains.
The priority on actual play also remains. A platform can accumulate architecture, automation and documentation until it forgets why any of it exists. In Blupoli Puzzles, the final test is still whether a person can open a game, understand what is in front of them and spend attention on the puzzle rather than on the interface. When a technical abstraction does not improve that direct experience or make it more sustainable to maintain, it deserves scrutiny. That link between architecture and player experience may be the clearest inheritance from the first Sudoku.
One puzzle taught us to think in systems
There is something slightly paradoxical about the origin. The project began small, and that small scale made every decision visible. Building one Sudoku forced questions about where rules live, what presentation owns, what should persist, what could be shared and how completion is recognised. In a mature product those questions might already have been hidden inside inherited infrastructure. Here they could be seen from the beginning, and they ended up shaping the growth that followed.
Not every early decision survived. Some abstractions were rewritten, new layers appeared, and a larger catalogue tested assumptions that looked solid with a single game. That is normal. A useful architecture is not one that predicts the future perfectly; it is one that makes change possible without turning every correction into demolition. The value of the first structure was not that it was final. It was that it allowed the second, third and later games to teach us something without forcing the whole product back to zero.
From a list of games to a way of discovering logic
Once a site hosts genuinely different puzzles, it gains an opportunity that a standalone game does not have: it can help people discover unfamiliar ways of thinking. Someone who arrives for Sudoku might move toward Kakuro, Nonogram, Slitherlink or a variant that breaks familiar habits. At that point the catalogue is no longer just inventory; it can become a map of experiences. That idea is behind grouping games by families and publishing material that explains the reasoning patterns or skills different challenges invite.
The Blog therefore became part of the platform too. Pieces such as the guide to cognitive puzzle categories connect games that might look unrelated when seen only as cards. Editorial content adds context without interrupting play: it explains, compares and suggests paths. It is another shared layer that did not exist in the first prototype but follows the same underlying goal. Growth should create more value and more discoverability, not merely more objects on a page.
The useful story is not “from one to many,” but “from one to a platform”
Measuring the project only by the number of games would focus on the most visible and least interesting part of its growth. What mattered was not that more cards appeared. It was that supporting them required one-off choices to become systems: understandable engines, reusable presentation, consistent metadata, navigable discovery, validation, shared identity and editorial context. Each layer reduces future repetition while also increasing what we expect from every new addition.
That is why the origin remains relevant even though today’s platform is different. The first Sudoku is not important out of nostalgia, and it certainly did not contain the complete architecture that exists now. It matters because it introduced the question that still organises the work: which part of this solution belongs only to this case, and which part deserves to become a shared capability? Answering that question repeatedly has shaped Blupoli Puzzles more than any fixed catalogue number ever could.
What a player arriving today should actually notice
Ideally, none of this architecture should demand attention from somebody who simply wants to play. The platform succeeds when internal decisions become a simple outward experience: recognisable navigation, games that load predictably, controls that feel related, instructions that make sense and an identity connecting the pieces. The complexity exists, but it stays behind the board. That is why infrastructure remains a means rather than the main event.
If you want to explore the result rather than the history, start directly at Blupoli Puzzles and pick a challenge. If you are curious about how it is built, continue through the articles linked here. Both routes should work. The product needs to be simple enough for the first and transparent enough for the second. The Blog gives us a place to explain the reasoning without turning the game interface into technical documentation.
Looking back is useful only when it improves the next decision
Rewriting this first post is not an attempt to preserve a time capsule word for word. The original article spoke from a project that was still named PuzzleHub and did not yet know the form it would take a few weeks later. Today we can keep the essential facts while explaining more clearly what they meant. We know the catalogue grew, the shared architecture became central and the brand eventually needed a wider frame. That perspective turns an announcement of birth into a useful account of how the current product came to exist.
It also avoids a common weakness in origin stories: pretending that everything was planned. It was not. There was no master document describing Blupoli exactly as it exists now. There was a direction, reversible decisions, experiments, refactoring and new questions as scope increased. Acknowledging that makes the story more accurate and more useful. Building well does not mean predicting the future. It means creating enough structure to learn without becoming trapped by the decisions that were sensible in an earlier stage.
The next puzzle is still the test
The best ending is to return to the first question. Whenever a new variant, catalogue feature, shared capability or separate product appears, we can ask: are we solving only this case, or have we learned something that should make the next one better? Sometimes the right answer is to keep a solution local. Sometimes it is to extract a reusable capability. The discipline is not to confuse reuse with automatic abstraction, or speed with accumulation.
Blupoli Puzzles grew from that conversation between one concrete game and a system that did not yet exist. First there was a Sudoku. Then came more challenges, more constraints and better questions. The name changed, the architecture matured and the catalogue stopped being an experiment, but the central idea survived: build each piece so playing today stays simple and improving tomorrow stays possible. That is the real starting point of Blupoli Puzzles.