De catálogo a sistema de descubrimiento
In September 2026, the project that was still called Blupoli crossed a threshold that looked purely numerical at first: the catalogue had grown beyond seventy games. Today the product is Blupoli Puzzles, and that number should not be read as a current counter. It is a dated snapshot of one stage in the project. What matters about the snapshot is not the total itself, but what it forced us to admit: a large collection eventually stops behaving like a set of pages and starts demanding the decisions of a platform.
Until then, much of the growth could be described with a simple picture. Every new game added another possibility. The catalogue became visibly larger, the home page gained another card, and the project felt more complete. The same mechanism became less helpful once the choices no longer fit comfortably in one mental pass. Adding more no longer improved the experience automatically. Sometimes it made the experience worse, because every addition made the existing catalogue harder to scan, compare and understand.
The moment a list stops being a catalogue
A list works when people already know most of its items or can inspect the whole thing with little effort. A catalogue has a different job: it must help someone choose among things they may not know. That requires structure. Names, categories, difficulty cues, descriptions, relationships and search stop being secondary metadata and become part of the main user experience.
The distinction sounds semantic until you design for it. If the home page merely orders cards, the design problem is mostly readability. If the home page must orient people, every card needs to answer useful questions. What kind of reasoning does this game ask for? Is it familiar or unusual? How demanding is it? Which other puzzles does it resemble? A catalogue is no longer an inventory. It is a guide.
Seventy-one experiences meant seventy-one chances to drift apart
Scale also amplified a quieter kind of debt. Each game had entered the project at a different moment. Some used native engines, others external integrations. Some had carefully refined controls, others still carried decisions from early prototypes. Spacing, onboarding, feedback, state, width and colour behaved differently across the site. No single inconsistency was disastrous. Together they created the sense that changing puzzle also meant changing application.
That is a common pattern in products that grow by accumulation. The first version of each screen solves a local problem, and without deliberate consolidation those local solutions become dialects. With five screens, users can absorb the differences. With dozens, the differences become product cost. We needed a shared vocabulary without erasing the mechanics that made each puzzle distinct.
The answer was not to make every board look the same
The tempting shortcut would have been a rigid template: identical layout, identical controls, identical density and almost identical presentation. That would have reduced some inconsistency, but it would also have ignored the value of a diverse catalogue. Nonogram needs edge clues and cell states; Sudoku needs candidates and boxes; Logic Grid needs matrices; Slitherlink lives on edges; a game against the CPU needs turns, an opponent and competitive feedback.
Useful consistency had to sit around those differences. Players should recognize how to start another session, change difficulty, find help, undo, understand a global state and return to discovery. The board itself should keep the representation that best expresses its logic. That boundary between a shared shell and a specific mechanic became one of the core architectural ideas in Blupoli Puzzles, later explored in our article on the shared UI system.
Sudoku became a laboratory, not a universal template
We chose Sudoku as a concrete place to develop the common experience rather than designing the system in the abstract. Its advantage was familiarity. If someone could not understand notes, selection or state, the problem was likely ours rather than a consequence of an unfamiliar rule set.
The point was never to copy Sudoku across seventy pages. The useful work was identifying decisions that survived a change of mechanic: hierarchy, actions close to the board, feedback, onboarding and theme behavior. We tested those ideas elsewhere before promoting them into shared patterns. That process — solve one experience deeply, extract the pattern later — is described in the Sudoku-as-laboratory story.
Page width can be a gameplay decision
One of the simplest findings was also one of the most revealing. The general container had proportions that felt comfortable for copy and simple pages, but larger boards were being squeezed by a rule that had not been designed for them. Limiting line length is usually helpful in editorial content. Applying the same measure to an interactive board can make the game worse.
Giving play surfaces more room was therefore not cosmetic. It meant recognizing the board as the primary content of the page. That distinction made it easier to separate reading measures from interaction measures and build layouts that could support both instead of forcing one global number onto every surface.
Light mode exposed hidden coupling
The early visual identity had grown around dark surfaces. Extending a light theme immediately revealed hard-coded colours, borders that only made sense on one background, selection states that depended too heavily on the original contrast, and components that had mixed structure with presentation.
Light mode became more useful than its label suggests. It was not merely another appearance preference; it behaved like an architecture test for the visual system. A component that can change theme through tokens and explicit states is usually better isolated than one that knows the exact colour of the page it first came from. A second theme turned invisible assumptions into visible rules.
Categories had to become discovery tools, not filing labels
With a small collection, a category can simply group. With a large one, it needs to explain. Labels such as numbers, paths, deduction or spatial reasoning only help when they let someone anticipate the experience behind them. We started enriching the taxonomy with mechanics, reasoning styles and relationships between families so that people could explore even when they did not know a specific game by name.
That also opened a more interesting path for recommendations: affinity of reasoning rather than raw popularity. Someone who enjoys local numeric constraints might discover Kropki. Someone who likes filling structures could move toward Nonogram. Someone who enjoys relational deduction might find Logic Grid or the Einstein Riddle. Taxonomy stops being administrative classification and becomes part of the interface.
Puzzles and games against the CPU needed different contracts
The catalogue also contained experiences that were still single-player but did not share the contract of a solution puzzle. Ataxx, Hex and Morris-like games involve an active opponent. They have turns, responses and competitive outcomes. Treating them as just another logic board made it harder to design statistics, difficulty and feedback honestly.
The product direction was to keep the overall experience focused on one person while separating games against the system from puzzles with a fixed solution. That lets them share identity, navigation and platform infrastructure without pretending they measure the same thing. Solving, winning, losing, drawing and beating a stronger opponent are different concepts and deserve different models.
Difficulty could no longer hide behind board size
A broad catalogue also exposed that “easy, medium, hard” meant different things across engines. Some games had approximated difficulty through size, others by removing clues, others by changing search depth. The variation was not automatically wrong — different puzzles have different structures — but it did require the label to mean something real within each mechanic.
A mature platform does not need one universal difficulty algorithm. It needs an honest product contract. If a setting is called hard, the player should experience a meaningful difference and the engine should have a mechanic-specific reason for it. That may involve logical techniques, branching, density, chain length or opponent strength. The public scale can be shared while the internal measurement stays specialized.
More games made it more important to finish the games we already had
Early in a platform, coverage is a useful learning metric. How many types of puzzle can the architecture host? Which mechanics force new boundaries? Exploration creates information. The same metric becomes less useful once the platform is already broad. At that point, improving generation, persistence, accessibility or onboarding across twenty games can create more value than adding a twenty-first unfinished experience.
That priority shift eventually became a more systematic audit, documented in our article about pausing expansion to audit. The underlying point is not that quantity and quality are enemies. They operate on different rhythms. There are moments to explore and moments to consolidate what the exploration taught you.
A large catalogue turns content into product infrastructure
Dozens of lesser-known puzzles cannot rely on interface alone to explain themselves. Rules, descriptions, articles and onboarding start doing discovery work. A name such as Norinori or LITS does not tell a newcomer what kind of interaction to expect. A card with only a title and a play button asks the user to choose blindly.
That is why editorial content and catalogue design started to converge. A good description can preview a mechanic. A category can explain what a family shares. An article can give context to someone who wants to go deeper. In Blupoli, the Blog, Devlog and puzzle pages work best when they behave as different routes through the same knowledge rather than isolated publishing systems.
Search could not be only a text box
If someone already knows a game name, text search is enough. The interesting problem begins when they do not know what to type. “I want something short,” “I want deduction without much arithmetic,” “I want something Sudoku-like but different,” or “I prefer paths and regions” are intentions an alphabetical list cannot understand.
The catalogue architecture therefore needed data that could eventually support filtering by name, category, mechanic, availability and other signals. Not every filter had to ship immediately. The architectural win was moving identity out of scattered HTML and into sources of truth that multiple discovery surfaces could use.
Centralized metadata reduced maintenance cost as well
Scale teaches a simple engineering rule: any fact copied manually across many places will eventually diverge. If a puzzle name, category or availability state is written independently in the home page, game page, navigation and editorial content, every change depends on human memory. At catalogue scale, human memory is not a system.
Moving identity and state into reusable data structures helped more than discovery. The same information could support statistics, sitemaps, navigation, localization and editorial tooling. Large products become easier to maintain when derived surfaces stop inventing facts and start reading them.
The platform had to learn to say “not yet”
A small collection tends to expose everything that exists. A platform that cares about quality needs a distinction between prototype, available game, experiment and future work. The expansion phase taught us that presence in the repository and public availability are not equivalent. That distinction later became more explicit when incomplete experiences moved into coming-soon states instead of being presented as finished.
The consequence is healthy: the catalogue becomes an editorial surface rather than a passive mirror of the file tree. Publishing means recommending. A game can still exist as development work while it waits for better generation, accessibility or interaction quality. The public state should communicate what we are prepared to stand behind.
Scale changes testing as much as design
With a handful of games, manual review can cover a meaningful portion of the product. With dozens, combinations explode: size, difficulty, language, theme, session state, breakpoint and engine family. A broad platform cannot make every release depend on one person revisiting every permutation.
Quality gates therefore started to protect repeatable invariants: routes, metadata, assets, engine coverage and other properties that can be proved automatically. That does not replace human review; it makes human review more valuable. When the system checks the basics, people can focus on harder questions such as whether difficulty feels right, whether onboarding teaches and whether a board uses space well.
Quantity stopped being a sufficient argument
Crossing seventy games was evidence of technical breadth and exploration, but it was also a warning. A big catalogue can impress once. What makes someone return is finding something relevant, understanding it quickly, playing without friction and discovering another experience worth their time. The number opens a door. Depth determines whether people stay.
That is why the phase mattered less as “we have many games” and more as a change of question. We stopped asking only how much we could add and started asking what system would make every future addition easier to discover, more coherent and more reliable than the previous one.
What that redesign left behind
Looking at Blupoli Puzzles now, several current responsibilities trace back to that moment: the split between shell and engine, richer taxonomy, centralized metadata, explicit availability states, shared UI, themes, stronger onboarding and a quality discipline that tries to demonstrate properties before publication.
Not every implementation survived unchanged, and it should not have. The value of a growth phase is not to guess the final architecture forever. It is to make new problems visible. A large catalogue forced us to see the product as a system rather than a pile of successful individual pages.
Game 72 should be easier to integrate and better to use than game 12
That became a more interesting maturity test than any counter. If each new puzzle requires more exceptions, more custom CSS and more tribal knowledge, the platform is getting worse even while the catalogue grows. If an addition can inherit navigation, states, accessibility, persistence and editorial structure, the system is accumulating capability.
The goal is not to remove all game-specific work. Each mechanic deserves specialized attention. The win is reserving that attention for what makes the puzzle special rather than rebuilding buttons, routes, themes or metadata. That difference is what turns a collection of implementations into a platform.
Growing well means making the next step cheaper, not more expensive
The lesson from September 2026 was not that some magical number transforms a collection. The threshold depends on the product. For us, a catalogue beyond seventy made it impossible to ignore frictions that were already accumulating. Scale acted like a magnifying glass.
We still use the same principle. A good local improvement should try to leave behind reusable capability. A new game should benefit from previous work. A new category should make discovery clearer. A new language should rely on an architecture that does not duplicate rules. A new article should connect existing knowledge instead of pretending nothing came before it.
Discovery is the work of reducing decision cost
There is another way to frame the problem that helped us order priorities: every new item increases the cost of choosing. With a handful of options, that cost is small enough to solve with scrolling. Once options multiply, the product needs to give some of that time back. Filters, categories, visual cues, history and recommendations are not decorative features of a large library; they are mechanisms that stop abundance from becoming paralysis.
This changes the job of the home page as well. It no longer needs to prove completeness by showing everything. It can present routes. One section can suggest a family, another can resume previous play, another can highlight something new, and a full catalogue can remain available when someone wants breadth. The home page stops being the place where the inventory fits and becomes the place where decisions begin.
Consistency needs explicit boundaries
We also learned that “make it consistent” is too vague to be useful. Consistency only becomes buildable when we know what should be shared and what should stay local. Navigation, action language, error treatment, availability states, focus patterns and the structure around the board are good system candidates. Geometry, clues, essential gestures and the representation of logic belong to the game.
Drawing that boundary prevents two kinds of debt. Shared concerns stop being duplicated, while specialized engines are not forced into abstractions designed for another mechanic. A mature platform is not the one with the fewest differences. It is the one that understands why its differences exist and gives them the right home.
Operational leverage matters as much as visual coherence
Once a catalogue reaches this scale, every shared decision has an operational value. A change that can be made once and inherited by dozens of games is qualitatively different from a change that must be copied into each screen. The former improves the platform and reduces future work; the latter may still be useful, but it increases the amount of surface that can drift later. This became a practical test whenever we considered a new component, metadata field or build step.
The same logic applies to defects. If five games show a similar spacing problem, fixing five CSS declarations is only the symptom-level answer. The more valuable question is whether those screens should have been using the same layout primitive. Scale rewards finding the shared cause. It turns maintenance from a series of local repairs into an opportunity to increase leverage.
A catalogue can be broad without forcing every choice into one interface
Another lesson was to resist the idea that discovery must happen entirely on the home page. A large collection benefits from multiple entrances: categories for people who think in families, search for people who know a name, editorial links for people who arrive through an article, history for returning players and direct game URLs for anyone coming from outside the product.
Those entrances should lead into the same underlying catalogue rather than maintaining separate, contradictory inventories. That is where central metadata becomes especially useful. A category page, a recommendation and a search result can present different views while still agreeing about the identity and availability of the game itself.
From counter to system
If we had to summarize that stage in one transition, it would be this: we stopped looking at the catalogue as a counter and started looking at it as a network of decisions. Every game has rules, but it also has a position in navigation, a relationship to categories, a visual experience, a quality state and paths toward other games.
That is what a platform adds on top of a collection. Not only more items, but context between them. Blupoli's growth made the problem visible; Blupoli Puzzles inherited the solution as an ongoing responsibility. Growth only remains useful if the product becomes easier to understand as it becomes broader.