There is a kind of growth that feels wonderful while it is happening and much less comfortable when you look back at it. Adding games to a catalogue creates an immediate sense of progress: a new card appears, a category gains variety, the project seems to expand in every direction, and there is always one more mechanic to explore. Blupoli Puzzles went through exactly that phase. We moved from a small collection to dozens of very different experiences in a short period of time. Some were already deeply developed. Some were useful prototypes built to test an idea. Others sat in the awkward space between the two: they opened, they allowed a player to finish a session, but they still lacked pieces we now consider essential before calling something finished.
The problem was not that we experimented too much. Those experiments taught us which layers could be shared, which puzzles required native engines, how onboarding should work, where persistence belongs, how accessibility changes board interactions, and how internationalisation affects more than text strings. The problem was that our public catalogue increasingly treated work in progress as if it were a final product. That gap between “it works” and “it is finished” became product debt. The larger the catalogue became, the harder it was to see clearly which games we could confidently recommend and which ones still needed another serious pass.
When the number stopped helping
During the expansion stage, talking about catalogue size made sense. Every new game was a convenient measure of construction speed. Eventually that number stopped representing what we wanted the product to say. A game that exists in the repository is not automatically a game that should be public. A board that can generate a session is not automatically a complete experience. An implementation that accepts legal moves is not automatically ready for someone who arrives with no knowledge of the project’s history.
That distinction sounds obvious once it is written down, but it changes incentives. If every experiment is shown as available, visitors cannot tell which ones are mature. If total game count becomes a goal, the team accidentally rewards adding a new card over finishing an existing experience. And if home pages, category pages and editorial posts repeat a fixed number, the editorial system itself starts pushing the product in the wrong direction.
That is why the recent change is more than hiding a few buttons. We changed the public definition of the catalogue. Games that have not yet passed our current quality bar are now labelled coming soon. They remain discoverable, they can show the direction of the collection, and they keep future mechanics visible, but they are no longer presented as finished playable products. Only completed games open into a live session.
The catalogue no longer asks “does this game exist?” It asks “is this game ready to represent Blupoli?”
What “finished” actually means
One of the most useful outcomes of this phase has been turning a vague feeling about quality into concrete questions. A game can have correct rules and still be unfinished. It can have a strong engine and fail on mobile. It can look polished while failing to preserve a session. It can generate boards without proving that those boards have a valid solution or meaningful difficulty. It can be excellent in Spanish while leaving untranslated fragments in English, Italian or French. It can feel comfortable with a mouse and become frustrating with a keyboard or assistive technology.
The per-game audit tries to look at the entire product. We start with the mechanic: rules, win conditions, impossible states, restart, new game and control behaviour. Then we review generation: seeds, reproducibility where it matters, validity, uniqueness for puzzle families that require it, and sensible generation budgets so the browser does not stall. Then comes the shared product layer: persistence, statistics, history, difficulty, sizes, onboarding, responsive behaviour, keyboard interaction, focus, contrast, visual feedback and copy.
The exact definition changes with the game. Ataxx does not need the same statistics as Akari. The 15 Puzzle does not model difficulty the way Sudoku does. Aquarium needs to reason about regions and water levels, while Battleship needs fleet constraints. The audit is not an attempt to impose one universal engine. It is an attempt to impose one universal expectation: whatever the mechanic is, a published experience should feel deliberate.
The recent audit wave gave us a clear signal
The last few days turned this approach into practice. Games such as the 15 Puzzle, Akari, Ataxx, Hidato, Balance Loop, Battleship, Aquarium and Takuzu went through much stricter reviews than “it opens and can be played”. In some cases the core was strong and the work involved completing the experience around it. In others we had to replace fixed boards or fallback logic with native engines, add verifiable generation, expand sizes and difficulty levels, or rebuild important parts of the game logic.
The same pattern kept appearing. The more closely we examined a game, the more obvious it became that finishing it well required focused time. Not necessarily weeks for every title, but enough attention that it could not coexist with the previous pace of catalogue expansion. Each audit exposed small details that collectively mattered: a control whose meaning was unclear, a state that did not persist, a layout that broke at one width, a statistic that was too generic, onboarding that demonstrated the wrong interaction, or a generator that worked but did not provide enough confidence about its output.
Our conclusion was not “we built too many games”. It was “we have learned enough to raise the bar”. That difference matters. We are not throwing away earlier work. We are treating it as an inventory of prototypes, engines and decisions from which we can now build a far more consistent collection.
Freezing a game does not mean abandoning it
Moving a game to “coming soon” can look like a step backwards. For us it is the opposite. Previously, a prototype could remain public for months without a clear signal that another pass was required. Now its status is explicit. The catalogue acknowledges that the game exists while also acknowledging that the work is not finished. That removes the pressure to pretend that every implementation is mature and gives us room to focus on one game at a time.
It also changes the internal conversation. Instead of asking what new game we can add next, we ask which incomplete game should receive the next audit. That forces us to close loops. When we choose a puzzle, fixing the first visible issue is not enough. We review the full experience until it meets the standard, or we document precisely what remains. The goal is not to make a branch look active. The goal is to move a game back into the playable catalogue with confidence.
This maps much better to the experience we want visitors to have. Nobody should need repository context to know which games are finished. Public state should explain itself. “Play” means we recommend it. “Coming soon” means it belongs to the planned collection, but we are not making that recommendation yet.
The counter had to stop being manual as well
The status change exposed another issue: we had mentioned specific catalogue totals in too many places. When the collection reached a particular number, that number appeared in home page copy, editorial posts and other surfaces. While the catalogue only grew, the mistake looked harmless. The moment we distinguished between published and upcoming games, a fixed number stopped having a stable meaning.
The right solution is to derive those values from real state. The catalogue already knows which games are released and which ones are still in preparation. Any surface that needs a count should read that source of truth instead of copying a literal. Publishing a new game then updates the value automatically, while temporarily moving another game out of the playable set no longer requires searching old sentences across the site.
This sounds like a small implementation detail, but it has an important editorial effect: we stop telling the story of the project through one number. We can talk about variety, puzzle families, mechanics and quality without binding every article to a total that becomes obsolete after the next merge.
An audit is not a blind checklist
We have been adding shared rules because they are excellent at catching regressions, but there is a danger in reducing quality to a wall of checkboxes. A game can pass twenty automated checks and still feel awkward. It can have every required ARIA attribute and still have a confusing interaction flow. It can respond correctly at three tested breakpoints and feel wrong on a particular tablet. It can store statistics perfectly while exposing statistics that are irrelevant to the mechanic.
That is why we separate gates from judgement. Gates make sure we do not forget the basics: assets, routes, translations, onboarding coverage, metadata, data contracts and other invariants code can test. Judgement starts after that. Does the first session make sense? Is the difference between difficulty levels perceptible? Is the primary action the right size? Do error states teach anything? Does undo behave in the way a player expects? Does the board use the available space without becoming hard to read?
A good audit combines both. We automate what is repeatable so that human attention can be reserved for the things that cannot be reduced to a boolean.
Every game moves through several layers, and none can replace the others.
What native engines taught us
Reviewing games individually has also moved us away from the temptation to solve very different puzzle families with one abstraction that is too general. We share the shell, controls, persistence and UI patterns when that makes sense, but the central logic often needs specific knowledge. A matching solver is useful for Dominosa; exact cover can be an excellent fit for certain placement puzzles; Akari needs to reason about illumination and constraints; Slant has a global cycle rule that does not disappear just because a generic API would be convenient.
The recent audits reinforced an architecture where sharing does not mean flattening. Each engine can express its rules clearly and prove the properties that matter for its sessions. Around those engines, players still receive coherent conventions: actions, state, interaction sizes, persistence and navigation.
This balance is another reason we are comfortable moving more slowly. Building a specific engine takes more work than forcing a mechanic into a generic component, but it reduces surprises later. Once the engine is sound, it also becomes a much better foundation for difficulty, reproducible bugs and future variants.
“Coming soon” improves catalogue design too
The new state does more than protect quality. It also makes the catalogue more honest and easier to browse. Previously, two visually identical cards could lead to very different levels of maturity. Now the interface can communicate that distinction before the click. Available games remain clear destinations. Upcoming games can still be shown as part of the roadmap without creating a false promise.
That gives us better design options than hiding unfinished work completely. We can group future releases, explain which puzzle family they belong to, link to development stories, or simply show that the collection is still expanding. The important part is that the call to action should not say “play” when playing is not yet what we want to offer.
It also fixes a problem in editorial linking. An article can discuss a puzzle we are still building, but it should not tell the reader to play now if the game is gated. Editorial content and catalogue state need to agree. That consistency is part of the system we are consolidating.
Quality includes what happens after a win
Early prototypes naturally focus on the board: place pieces, mark cells, move tiles, validate an answer. The audits are widening the frame to the whole session. What happens when you finish? Is the result persisted? Do statistics distinguish size and difficulty? Can you start another game without reloading? Does history make sense? Does completion feedback celebrate the result without trapping the player?
Competitive games need a different cycle. Ataxx represents a match against the CPU and its results should not conceptually collapse into the timing model of a logic puzzle. Move-count games care about different information from deduction puzzles. Elsewhere, the relevant measure might be a streak, accuracy or simply completion.
“Finished” is starting to mean that we considered those layers as well. Not every game needs every feature, but every feature that exists should have a reason.
Responsive stopped being a final check
Another repeated lesson is that a board that looks good on desktop is nowhere near done. Many puzzles are especially well suited to smaller screens because a short session fits naturally on a phone or tablet. If clues, controls or cells become tiny, we have failed in one of the product’s most important contexts.
The audit forces us to look at the shell and the mechanic together. Sometimes the issue is board sizing. Sometimes the action bar takes too much room. Sometimes controls were built around hover. Sometimes an outside clue needs a different arrangement. We have started treating breakpoints as product decisions instead of late CSS patches.
The same principle applies to the footer, navigation and other shared pieces of the site. Game quality does not stop at the edge of the board. From the moment someone opens a game page until they return to the catalogue, the experience should keep the same level of intent.
Accessibility and onboarding belong in the publishing engine
One of the biggest changes of the last few weeks was stopping ourselves from treating onboarding as generic copy. Dozens of mechanics cannot be taught with the same example. We created reusable profiles for families that share an interaction, but every game still needs an explicit assignment. Continuous integration can then catch a new game that ships without coverage.
Accessibility follows a similar principle. Some patterns are common — visible focus, accessible names, touch target size, contrast — but every board needs specific decisions. An editable grid can map naturally to the keyboard. A draggable piece may need an alternative control. A connection puzzle has to communicate state without relying only on colour. We do not want to call something accessible because the attributes are syntactically present. We want the core interaction to have a real path for different modes of use.
This is another reason to slow down publication. These layers rarely appear when the target is “add the mechanic as quickly as possible”. They do appear when the target is “finish the product”.
What happens to games that were already public
We are not attempting to fix the entire catalogue in one giant operation. That would be difficult to review and would make every regression harder to isolate. We prefer an incremental migration: identify the next incomplete game, audit it, implement what is missing, verify it, then move on. Games that have already passed this process stay available. Games that have not can remain visible as upcoming.
This approach also lets the audit process improve itself. Something discovered in Aquarium can become a rule that helps another region-based puzzle. Lessons from Ataxx’s CPU can become a pattern for competitive statistics. A responsive issue found in one board may be solved in the shared shell and benefit dozens of games.
The queue is not rigid. Some audits will reveal only small work. Others will demand a new engine. Priorities may change when a shared dependency becomes obvious. What matters is that public state stays transparent and that we stop confusing presence in source control with product availability.
Less visible speed, more compounding progress
From the outside, this phase may look slower. We will probably publish fewer brand-new names for a while. But every game that exits the audit leaves reusable improvements behind: better components, better contracts, more precise tests, cleaner translations, accessibility patterns, data decisions and generation tooling. The next game begins from a stronger baseline.
That changes what progress looks like. Previously you could see it in catalogue length. Now you see it in consistency. A button behaves the same way across mechanics. A session survives reload. A difficulty level has an algorithmic reason. A tutorial teaches the right gesture. A board survives the move from desktop to mobile. A card never promises a playable game that we are not ready to recommend.
That kind of progress is less photogenic, but it is how a collection of experiments becomes a product.
How we decide a game can reopen
There is no single score that automatically decides publication. There is, however, a set of signals. The engine must respect the rules and avoid known invalid states. Generation must be sufficiently reliable for the puzzle family. Sizes and difficulty levels must correspond to real implementation rather than labels. A session must start, continue and finish without losing important state. The interface must work across the screen sizes we support. Onboarding and copy must match the mechanic. Automated checks must pass.
Then we ask a human question: would we put this in front of someone without explaining that “it is still kind of unfinished”? If the answer needs an excuse, the game is still in progress.
We like that question because it forces us to think about the whole experience. It also prevents a checklist from becoming a way to negotiate around obvious problems. Quality does not mean absolute perfection; there will always be improvements left. It does mean that the current public version is coherent, reliable and defensible as a finished product.
What changes for people visiting Blupoli Puzzles
The visible change is simple: fewer games with a Play button, more cards clearly labelled coming soon, and a playable collection that grows more deliberately. We do not see this as reduced ambition. The roadmap remains broad. The difference is that “finish it properly” is now part of the ambition.
Visitors looking for variety can still discover future mechanics. Visitors who want to play get a much more reliable signal about what we recommend today. And when a game moves from coming soon to available, that change will mean something concrete: it has been through review and we believe it belongs in the active collection.
We will keep documenting the important parts of that work in this Devlog. Not every fix deserves an article, but changes that reshape how we build do: engines we had to replace, abstractions that failed, tests that became contracts, and patterns that ended up helping many games at once.
The next chapter is written one game at a time
The previous stage of Blupoli Puzzles was expansive. We needed to test how much could be shared, how many puzzle families could fit under one product, and what architecture emerged when we built many mechanics. That stage did its job. The current stage is different: turning breadth into depth.
That is why the new rhythm is deliberately simple. We choose one game. We audit it properly. We fix the engine and the surrounding experience. We verify it. We publish it when we are comfortable putting the Blupoli name on it. Then we move to the next one. In the meantime, the catalogue can still show the future without confusing it with the present.
We do not yet know how long every audit will take, and pretending to have an exact cadence would not be useful. We do know what we want to optimise. Not the number of cards. Not a headline count. We want to optimise the confidence that when Blupoli Puzzles shows a Play button, there is a game behind it that we made a deliberate decision to finish.
If you want the technical background, read why finishing a puzzle is much more than making it playable, the story of turning Aquarium into a complete engine and experience, or our earlier piece on auditing before building. If you would rather see the collection itself, the Blupoli Puzzles catalogue now distinguishes between what is ready and what we are still preparing.