Blupoli Puzzles has changed dramatically in a short period of time. What started as a compact collection of browser puzzles grew into dozens of mechanics, categories and ways to play. That expansion was useful because it helped us discover what kind of platform we wanted to build. We tested logic grids, number puzzles, spatial games, CPU opponents, hint systems, generators, statistics, onboarding, themes and shared navigation.
Fast growth also has a cost. Not every game progressed at the same pace. Some received deep reviews, native engines, verifiable generation, multiple sizes, difficulty levels, persistence, statistics, accessibility work and internationalisation. Others remained much closer to prototypes: functional, sometimes enjoyable, but still missing the depth, polish or reliability we now want a published Blupoli game to have.
Instead of continuing to expand the catalogue as if every title were at the same stage, we are moving into a different phase. From now on, games we do not yet consider finished will be clearly marked Coming Soon. They will remain visible as part of the Blupoli Puzzles roadmap, but they will not open into a playable session until they have passed a full review.
Why we are comfortable showing fewer playable games
It may sound counterintuitive for a platform with a broad collection to reduce the number of currently playable titles instead of celebrating an ever-larger total. The reason is simple: the number alone does not describe the experience. Fifty consistent games can make a much better platform than seventy experiences where some are complete and others are only partially ready.
We want the word “Play” to mean something. If a title is shown as available, you should be able to open it expecting a complete experience: understandable rules, controls that make sense, a board that behaves correctly on desktop and mobile, a session that persists when it should, and an overall feeling that the game was reviewed as a product rather than merely left online after an experiment.
“Coming Soon” lets us be transparent without hiding the future. You will still see games that are on the roadmap, but the interface will no longer pretend they are ready. When one of those cards changes state, the transition will be meaningful: the game has passed through our current quality process and we are comfortable presenting it as an active part of the catalogue.
The catalogue now separates what you can play today from what we are still preparing.
What “finished” means to us
We do not use “finished” to mean that a game will never change again. There will always be opportunities to improve details, add variants or refine a piece of the experience. We use it to mark the quality floor we are willing to publish.
That floor starts with the obvious: rules need to be implemented correctly, a session must be completable and controls should behave consistently. But it goes much further. A published game needs to work across supported screen sizes, teach its mechanic reasonably well, present understandable error states, preserve progress when appropriate and offer difficulty that reflects real differences rather than a cosmetic label.
Generated puzzles need their own guarantees. Some require a unique solution. Others need to guarantee that a valid path exists. In other families, the important question is whether difficulty actually changes between levels. There is no universal recipe, so every game is reviewed according to the mechanic it implements.
We also look at less visible layers: keyboard support, focus, contrast, copy, translations, statistics, history, restart behaviour and what happens after a puzzle is completed. The full experience matters just as much as the board.
The decision grew out of the latest audits
Over the last several days we have been reviewing games that already existed on the platform but needed a stricter definition of ready. That work has included titles such as the 15 Puzzle, Akari, Ataxx, Hidato, Battleship, Aquarium, Takuzu and others.
The useful part was not discovering one repeated bug. The opposite happened: each game needed something different. One required better generation. Another needed persistence completed. Another had mobile interaction problems. Some needed more specialised engines. Others had a sound core but lacked onboarding or a coherent integration with the rest of the product.
That work led to a clear conclusion. Finishing a game properly requires focused attention. We cannot do that while still treating catalogue growth as a race to add the next card. So the priority changes: fewer continuously added prototypes, more complete passes over the games already on our roadmap.
Upcoming games are not disappearing
We do not want to hide everything that is still in development. Part of the appeal of Blupoli Devlog is showing where the project is going. That is why unfinished games will continue to appear in the catalogue, but with a different visual treatment and a different promise.
A Coming Soon card can help you discover a future mechanic, understand the range of the collection or follow a development story in the Devlog. What it will not do is invite you to play an experience we are not ready to recommend.
This also gives us more honest design options. We can visually distinguish states, avoid misleading calls to action and create a real sense of roadmap without turning the catalogue into a list of vague promises. If a game is announced, it belongs to something we want to work on. If it is available, it has reached the required level.
Quality matters even more in a puzzle platform
Product problems are especially frustrating in puzzles because they undermine trust in the logic itself. If a player cannot tell whether they made a mistake or whether the generator produced a problematic board, the experience breaks. If a clue contradicts the state, a valid solution is rejected or a difficulty label changes nothing, the issue goes beyond visual polish.
That is why we want every published title to carry more confidence. The person playing should be able to assume that the rules are coherent and the system is not improvising. In some puzzle families that means checking solutions. In others it means making sure every generated board is solvable. In games against the CPU it means difficulty levels should produce meaningfully different behaviour. In movement-based games it means controlling reachable states carefully.
Not every property can be proven mathematically in every mechanic, but every engine can be designed with the guarantees that matter to its own rules.
We are also reviewing how games teach themselves
Quality does not stop at the logic. A great mechanic that is badly explained produces a poor first session. During the expansion phase we reused help patterns wherever it made sense, and that was useful for learning. We are now refining that into a system where every game has an explicit relationship to an onboarding profile that actually fits.
Some games share gestures and can reuse a common explanation. Others need a different demonstration. Sudoku, Akari and Ataxx should not all begin with the same tutorial just because they use grids.
The per-game review includes this layer as well. We want someone to understand the first meaningful action without having to search elsewhere. That does not mean turning tutorials into manuals. The goal is the opposite: teach the objective, the first important interaction and the rules most likely to cause confusion, then let the game take over.
Mobile and tablet are no longer secondary adaptations
Many puzzles are particularly well suited to touch screens. A short logic session fits naturally into a commute, a break or a few quiet minutes. That means we cannot design primarily for desktop and simply shrink everything later.
The current audits include how every board behaves on phones and tablets. Sometimes we need to change cell size, rearrange clues, regroup actions or adjust an interaction for touch. In other cases, the problem sits outside the game itself: navigation, footer behaviour, spacing or controls that are too small.
That work is already improving shared parts of the site. The more carefully we finish one game, the more opportunities we find to raise the baseline for all the others.
We do not want the catalogue count to drive decisions again
During the growth phase we repeated the total number of games in several parts of the website and in some articles. It was an easy way to communicate scale. It is no longer the right model.
The catalogue now distinguishes between released and upcoming games, and it will keep evolving. Any count we need to show should come from real data rather than manually written copy. When a game changes state, the website can update consistently without relying on someone remembering to change half a dozen pages.
More importantly, we want to stop using the total as the main value proposition. Blupoli Puzzles should not be interesting because it has one particular number of titles. It should be interesting because it brings together strong mechanics, a coherent experience and a collection worth exploring.
What happens to games that have already passed an audit
Titles that have already been reviewed in depth will remain playable. Several of them have received substantial work recently: native engines, stronger generation guarantees, real difficulty differences, additional sizes, improved responsive behaviour, statistics and game-specific onboarding.
That does not freeze them forever. We will keep fixing bugs and refining details. The difference is that they have already gone through the process we now want to make standard for the rest of the catalogue.
Each finished game also becomes a reference point. It teaches us something reusable: a persistence pattern, a way to represent difficulty, a keyboard interaction, a statistics model or a generation technique. The completed collection therefore does more than grow; it improves the foundation for the next audits.
More consistency around very different games
One of the things we like most about Blupoli Puzzles is that the mechanics can remain genuinely different. We do not want every game to feel like a skin over one generic grid. Aquarium should feel like Aquarium. Ataxx should have its own rhythm. A connection puzzle needs different signals from a number puzzle.
The consistency we want lives around the mechanic: navigation, actions, state, interaction size, themes, persistence, feedback and the way a new player learns what to do. That shared layer lets someone move from one puzzle family to another without relearning the website itself.
Auditing one title at a time is the best way to find the right balance. If we force a universal component too early, we lose the richness of the mechanics. If every game solves everything independently, the platform becomes a collection of unrelated mini-sites. The audit forces us to decide what should be shared and what should stay specific.
What you will notice in the catalogue
The most visible change is the new status treatment. Games still under review will show that they are coming soon and will not start a playable session. Available games remain direct destinations.
We are also correcting old copy that referred to a fixed total. The number of published puzzles should be derived dynamically from the actual catalogue source. That keeps indexes and other surfaces in sync as game states change.
Over time, the biggest improvement should be less visible: greater consistency. You should not need to wonder whether a game is “really finished”. Controls, onboarding, statistics and responsive behaviour should feel as considered as the core mechanic. Different areas of the platform should increasingly feel like one product.
A game stops being “coming soon” after it has moved through the whole process.
This phase does not reduce our ambition
We still want a broad collection. We are still exploring new mechanics and we still see enormous potential in a platform that can bring together very different puzzle families. What changes is how we get there.
We would rather take longer and build a library we can recommend confidently. We would rather let the catalogue grow when a game is ready than when a prototype merely exists. We would rather have a large total emerge as the consequence of finishing many experiences than use the number as a target that distorts decisions.
In that sense, this is a sign of the project maturing. The first phase needed breadth to discover the architecture. The next phase needs depth to turn that architecture into a stronger product.
How we will choose what to finish next
We are not publishing a rigid release calendar because every audit can reveal a different amount of work. One game may need a few adjustments and be ready quickly. Another may need its generator or a large part of the interface rebuilt. Promising dates before understanding the work would turn transparency into unreliable forecasting.
The priority is to work through incomplete games and close loops. We will also consider whether a change benefits several mechanics at once. If one audit reveals a problem in a shared component, solving it may make later reviews faster.
What we do want to keep is the communication rhythm. The Blog will cover changes that affect the public product, while the Devlog will document the most interesting engineering decisions behind those changes.
An honest catalogue is a better roadmap
We like keeping future games visible because it turns the catalogue into more than an inventory. It shows where the platform is heading, introduces mechanics that are not ready yet and gives development stories a concrete home.
The difference is that status now carries meaning. Coming Soon is not a decorative badge that can be forgotten. It is acknowledged unfinished work. As audits are completed, we want those cards to visibly move into the playable collection.
That transition may become a more interesting way to follow Blupoli’s evolution than any total count. Every state change tells a small story about something becoming a finished product.
The website is changing around the games too
This catalogue change is not happening in isolation. At the same time we are reorganising Blupoli’s identity, unifying the logo, improving the shared header and footer, separating Blog from Devlog and making navigation between the brand home and Puzzles more coherent.
The underlying idea is the same: stop treating every improvement as an isolated patch and build a more consistent system. Games are the heart of Blupoli Puzzles, but the experience starts before a board opens and continues after a session ends.
That is why the new phase affects engines, design, content and architecture together. We want everything around the game to reinforce the feeling that the collection is cared for.
What you can play while the next games are being finished
The games that are currently available remain open, and we will keep improving them. You can explore the Blupoli Puzzles catalogue and choose from the experiences we currently consider ready. When a card is marked Coming Soon, you will know it belongs to the roadmap but has not completed its review.
If the technical side interests you, the Devlog will keep explaining how those audits work and what we learn while completing each engine. A good place to start is Quality before quantity, where we go deeper into the publishing decision. You can also read Finishing a puzzle is more than making it playable, which captures many of the layers we now review systematically.
The promise of this new phase
We are not promising that every upcoming game will be available immediately, or that every audit will be quick. What we can promise is a clearer direction.
Blupoli Puzzles is moving away from growth by accumulation alone. From now on, growth is tied to completion. Every game that becomes available should justify that change with a complete experience. The catalogue can still be ambitious, diverse and large, but quality is no longer a task for later. It becomes the condition for publication.
For a while you may see fewer Play buttons than before. We hope that, in return, every one of those buttons will mean much more.