Escalar sin multiplicar mantenimiento
There is a particularly satisfying phase in building a game platform: every new addition changes the catalogue in an obvious way. One Sudoku becomes a small collection, then Nonogram appears, then Kakuro, Slitherlink and other families. The number rises and it can feel as though the product is improving at the same rate. During the first phase of the project—when it was still called Blupoli Puzzles—that expansion was intentional. We needed enough variety to discover which problems were truly shared and which only belonged to one puzzle.
Growth eventually changes its meaning. Once there are dozens of experiences, the useful question is no longer “can we add another game?” It becomes “can we maintain all of these games, improve them consistently, and help somebody choose among them?” At that point the catalogue stops being merely an output of the architecture and starts putting pressure on it. Blupoli Puzzles today reflects several decisions that only became obvious when quantity stopped being a goal and started becoming a stress test.
Early coverage was a way to learn, not the final objective
If we had tried to design a universal puzzle architecture before building variety, we would have been guessing at problems we had not yet met. Implementing different families gave us much better evidence. Grid classics, shading puzzles, path puzzles, Sudoku variants and deduction games do not ask for exactly the same interaction model. Each addition taught us which part of the frame could be shared and which part needed freedom.
That phase was valuable even when some implementations were simpler than what we would want to preserve forever. The catalogue acted as a collection of experiments. It revealed recurring navigation patterns, control conventions, accessibility needs, generation differences and layout limits. Broad coverage is useful when it teaches you what system the product actually needs. It becomes a distraction when the number itself becomes an excuse not to deepen what already exists.
Small inconsistencies multiply faster than the games themselves
With three pages, moving a control manually feels cheap. With thirty, the same decision becomes work. Beyond that, the bigger problem is divergence: slightly different versions of the same pattern begin to coexist. A button moves, help copy uses another convention, victory is communicated differently, or one mobile screen preserves an old layout the newer games have already abandoned. Scale turns tiny inconsistencies into product and maintenance problems.
The positive effect is symmetrical. Good abstractions multiply too. Improve a shared control system and several games benefit. Fix keyboard focus in a common layer and accessibility can rise across the catalogue. That ability to propagate quality is one of the reasons separating engines from the platform became so important. Once the collection is large enough, architecture determines how expensive it is to raise the standard.
The catalogue becomes an interface of its own
A small collection can be shown as a list. As the number of choices grows, that list begins to demand cognitive work from the visitor. People need to understand how one puzzle differs from another, what they might enjoy if they like a certain kind of reasoning, and how to find something familiar without already knowing every name. The problem is no longer displaying cards. It is designing discovery.
Categories then acquire a real product role. They should not be administrative buckets; they should be signals that reduce choice overload. Grouping by mechanics, reasoning style or family can help somebody move from the familiar toward something new. Our guide to cognitive puzzle categories grew from the same need: explain relationships an alphabetical list simply cannot reveal.
More variety forces a separation between game rules and product rules
When every game looks similar, it is easy to accidentally bake one puzzle’s assumptions into components that are supposed to be generic. Variety breaks that illusion. A board with outside clues, another built from connections, and another that is not naturally a rectangular grid make it clear that the common layer cannot dictate the internal semantics of every game. It should provide a home, not a straitjacket.
That lesson helped shape engines with their own responsibilities and a platform responsible for navigation, integration, themes, global controls and other repeated behaviour. The architecture does not try to make every puzzle the same shape. It tries to let each puzzle express its own shape without rebuilding the entire application. The more examples arrive, the more important it becomes for boundaries to follow responsibilities rather than the geometry of the first game.
The definition of “done” becomes much stricter
In an early prototype, a game can feel complete once it accepts actions and recognises a solution. In a large catalogue that is nowhere near enough. It needs to launch from the right card, explain its rules, respond well to keyboard and touch, fit the available space, manage restart and state, provide understandable feedback and coexist with expectations created by the other games. The whole product becomes part of the definition of done for each individual puzzle.
Scale also makes omissions visible. If ten games support a familiar interaction and the eleventh does not, the exception stands out. That does not mean every game needs identical features, but differences should have a reason. Useful consistency is not uniformity. It is the confidence that behaviour belonging to Blupoli Puzzles is predictable while each puzzle keeps the details that make its own logic interesting.
Parity does not mean copying implementations
As the catalogue grew, some lessons also came from work on other surfaces, particularly earlier Android experiments. Reusing that knowledge does not mean porting every technical detail. A web product and a native application have different constraints. What can travel are game rules, UX decisions that proved useful, mental models and mistakes we no longer need to repeat.
This matters because literal parity creates two platforms trying to imitate each other internally. We prefer behavioural and experiential parity where it makes sense, with architecture appropriate to each environment. That remains compatible with wrapping the web for mobile if that direction is useful, but it does not depend on it. The durable asset is not identical code. It is product knowledge explicit enough to apply in more than one place.
Sizes and difficulty labels need a common grammar
As more games appear, words such as “easy,” “hard” or “large” begin to mean different things. In some puzzles size directly changes the search space. In others, a small board can contain a much deeper deduction than a large one. If the platform uses the same labels without a real model behind them, it creates a false sense that the categories are comparable.
We need a common grammar, not one universal formula. Different families can measure different signals, but the label should correspond to a real, perceptible change. Difficulty might depend on techniques, number of decisions, branching, clue density, reasoning length or spatial structure. The important thing is that “hard” is not decoration. It should create an experience meaningfully different from “easy” and do so consistently enough for players to learn what to expect.
The dangerous case is not invalid—it is valid but boring
Obvious failures are easy to prioritise. A puzzle that will not load, a broken rule or an impossible solution demands attention. The harder case is an implementation that technically works but does not deserve the player’s time. A generator can produce solvable boards that are trivial, repeat the same patterns or raise size without raising reasoning. Once the catalogue is broad, those depth problems matter more than the absence of one extra game name.
Numberlink was one of the early examples that forced us to confront this. A board can be valid while the paths are far too obvious. That changes the quality definition. A mature game requires thinking about correctness, variety, uniqueness where relevant, difficulty, generation time and the sense of progression between levels. Our piece on generation and solving goes deeper into that separation.
A large catalogue needs a quality policy, not just tests
Tests verify individual properties; a quality policy connects several layers. We can think in four questions. First: do the rules work? Second: are the generated or selected puzzles good enough? Third: is the experience coherent and accessible? Fourth: is the game properly situated in the product, with the right description, category, help and links? A game can pass one layer while failing the next.
This prevents a green CI result from becoming shorthand for “finished product.” Automated checks are essential, but they cannot decide whether a puzzle is dull or an explanation is confusing. A quality policy combines technical evidence with experience review. In a small library this can happen informally; in a large one it is worth making the gates explicit so every new addition is judged against the same broad standard.
Screen space stops being an editorial layout decision
A website that begins as content may adopt a comfortable reading width and reuse it everywhere. Puzzles challenge that assumption. Some boards need space. Others combine side clues, controls or contextual information that do not fit naturally in a narrow column. Forcing every experience into the same width does not create coherence; it can make the game worse.
Giving game pages more room looks like a visual redesign, but it expresses an architectural rule: the platform must adapt to the needs of the interactive content it hosts. The common frame can establish limits and responsive behaviour, but it cannot treat a game screen as an article with a grid inserted in the middle. Scale made that difference impossible to ignore and pushed the board toward being treated as the primary surface.
Share components only after finding the real pattern
The second game creates a strong temptation to abstract anything that has appeared twice. Dozens of games teach the opposite lesson: some repetition is accidental. Two puzzles may share a button while requiring entirely different state. Three may use grids and the fourth may break every assumption the shared renderer made. Generalising too early produces components that seem reusable until they fill up with exceptions.
Scale gave us enough examples to extract shared pieces with greater confidence. Common actions, page structure, help, global states and onboarding patterns can use the same language when the responsibility is genuinely the same. Boards and specialised interactions keep their freedom. The result is not one enormous component library. It is a collection of smaller pieces with narrow contracts and less knowledge of individual games.
Consistency becomes a maintenance tool
When a player learns where restart lives, how to return to the catalogue or what a selected state looks like, they should not have to relearn those conventions arbitrarily in every puzzle. That coherence reduces friction. It also reduces internal cost. If the same pattern has one shared implementation, changing it requires less work and produces less drift. UX and engineering benefit from the same decision.
This matters because platforms age. We do not want the earliest games frozen at the quality level of the week they were created. A lesson learned later should be able to propagate backward when it belongs to a common layer. The larger the catalogue becomes, the more valuable that capability is. Maintaining dozens of experiences is not just keeping them from breaking; it is being able to raise their standard without rebuilding each one in isolation.
Discovery matters as much as construction
An excellent game nobody can find adds little value to a catalogue. With a handful of options, visitors can scan everything. With dozens, information architecture determines what effectively exists for each person. Families, filters, editorial recommendations, search and related routes turn a static collection into a discovery system. That layer does not live inside the engines, but it changes how much value those engines can deliver.
The Blog contributes because it can explain relationships that do not fit on a card. Somebody who enjoys Sudoku might discover other deduction puzzles; somebody drawn to visual patterns may find Nonograms or shading games. Editorial content does not replace good navigation, but it adds another way through the catalogue: by curiosity, skill or reasoning style rather than only by name.
Performance changes shape when experiences multiply
A heavy page is a local problem. A heavy pattern repeated everywhere becomes a platform characteristic. At scale, shared costs matter: bundles, assets, initialisation, generation logic, event listeners, fonts and anything loaded by default. Architecture should avoid making every game pay for every capability another game might need.
This encourages loading features when required, keeping engines relatively isolated and asking which global components truly deserve to be present everywhere. It also affects generation. A more expensive algorithm can be acceptable when it runs outside the critical path or has a clear budget; it can be unacceptable if it blocks interaction every time the player asks for a new board. Performance and product design meet again.
Localisation multiplies another dimension of the catalogue
Dozens of games in one language already create a large maintenance surface. Additional languages multiply titles, descriptions, instructions and routes that must remain coherent. A phrase hard-coded next to a button in a prototype stops being a small detail when the same pattern appears in many experiences and multiple locales. Growth forces content and logic apart too.
Later internationalisation work confirmed a lesson we had already learned from game engines: sources of truth matter. If one name exists in three files and one description in two templates, translations drift. When catalogue, interface and editorial content have clear contracts, coverage can be checked and missing pieces can be detected. Scale is not solved by remembering more. It is solved by reducing the number of places where the same decision can contradict itself.
AI accelerates expansion—and debt
AI agents make it possible to produce implementations, variants and content much faster. That makes structure more important, not less. A bad convention can be repeated across dozens of files before anyone recognises the pattern. A good source of truth and a good quality gate, on the other hand, let many tasks follow the same standard without relying on manual reminders.
In how we use AI in the development workflow, we describe why context and evidence are essential. The catalogue is a perfect example. Speed without acceptance criteria creates more surface area, not necessarily more product value. The ability to generate must be matched by the ability to review, consolidate and remove work that does not reach the standard.
Reaching dozens changes the priority from coverage to depth
The original version of this story was written at a moment when the project was celebrating broad coverage and explicitly referred to more than seventy options. That number mattered because it showed the architecture had been tested against many puzzle families. It also marked a phase change. Adding another name no longer produced as much learning or value as improving the catalogue already in front of us.
The priority started shifting toward depth: review generators, improve help, strengthen responsive behaviour, consolidate controls, organise categories, make difficulty meaningful and audit whole experiences. That work is less visible than publishing ten new cards, but it affects far more play sessions. Catalogue growth taught us that real scale is not measured only by how many things a system can host. It is measured by how many it can continue to host well.
Architecture matures when it lets you correct the past
A platform should not force its first few weeks of decisions to become permanent law. If the architecture is too rigid, every global improvement becomes a large migration. If it is too loose, there is no shared place where improvements can be applied. The useful middle is a set of contracts stable enough to share capabilities and small enough to evolve when evidence changes.
This is why refactoring remains part of the work. We are not trying to discover one final structure. We are trying to maintain a structure that lets us revise assumptions without demolishing the catalogue. New games test the boundaries; older games test whether improvements can propagate backward. The platform becomes more mature when both moves—adding and correcting—remain reasonably affordable.
A strong library makes each new addition more valuable
At the beginning, the marginal value of a new game comes almost entirely from that game. In a mature platform, it also comes from the environment around it. A new puzzle can immediately benefit from navigation, controls, accessibility, categories, documentation, localisation and editorial context that already exist. In return, it can strengthen a family or create a new discovery path toward older games. The whole begins to produce effects a folder of independent pages cannot.
That is the real difference between “many games” and “a game platform.” It is not a specific number. It is a system where the platform improves the pieces and the pieces provide evidence that improves the platform. Blupoli Puzzles is still working on that balance. The catalogue is much larger than the first Sudoku, but the question remains familiar: what should we learn from this game so the next one—and the earlier ones—work better?
Scaling means preserving the ability to choose well
The paradox of growth is that more possibilities appear while the ability to say no becomes more important. Not every abstraction should become shared infrastructure. Not every puzzle deserves publication the moment it technically works. Not every variant adds enough difference to justify its cost. The system needs criteria for rejecting complexity in the same way a generator needs criteria for rejecting weak candidates.
That is why the next chapter of Blupoli Puzzles is not about filling an endless shelf. It is about making sure every part has context, quality and a reason to exist. The expansion phase gave us a map of the problem. The platform phase is about using that map to reduce friction, increase depth and make a diverse collection feel coherent without erasing the qualities that make each puzzle worth playing.