What Shipping Our Own Puzzle Games Taught Us About Launch

We have thirteen apps live on Google Play under our own developer account, five of them puzzle titles released during 2026. Building them is client work done at our own expense, with one difference that changes everything: when a release goes wrong there is no client to absorb it, so we feel every mistake directly.

What follows is what that has actually taught us. It is deliberately not a list of growth tactics, because those are not what cost us time.

The build is finished long before you can release it

The gap between a working game and a published one is almost entirely administrative, and the first time you cross it the gap is enormous. Store listing text, screenshots at the right sizes, a privacy policy that exists at a real address, content rating questionnaires, data safety declarations, target API levels, and a signing key you must never lose.

None of this is difficult. All of it is slow, and all of it blocks. The mistake we made early was treating it as the end of the project rather than as a workstream of its own, so it got started when the game was done instead of alongside it. We now open the listing while the game is still being built, which turns a week of blocking admin into something that happens in the background. The specifics are in our Google Play release walkthrough.

The declarations deserve particular care, because they are the ones that come back. An answer in the data safety form that does not match what the app actually does is a rejection, and it is also the kind of rejection that makes a reviewer look harder at everything else. We go through the common rejection reasons before every first submission.

A puzzle game cannot be tested by playing it

This is the lesson that genuinely changed how we build. In a puzzle game, the worst possible defect is a level that cannot be completed. It does not crash. It does not fail a conventional test. It looks exactly like a hard level, and the player's conclusion is not that your game has a bug but that your game is unfair, which is the one impression you cannot recover from.

Playing through levels by hand does not find these, because the person checking designed them and knows the solution. So the levels are verified by machine instead: a solver works through each one and the build fails if any level cannot be finished. One Move Left goes further, because its premise requires each of its hundred levels to have exactly one winning move, and a solver is the only honest way to assert that.

The general principle transfers well beyond games. Where the correctness of your content can be checked by a program, check it with a program, because human review of generated content is the step that silently stops happening under deadline.

Collecting nothing is an engineering decision

Our puzzle titles are free with ads, collect no data and share none with third parties. That sounds like a policy position and is really a series of engineering constraints accepted up front.

It means no accounts, so progress lives on the device and the design has to accept that a reinstall starts again. It means no analytics, so questions about which level people stop at cannot be answered by looking, and have to be designed for in advance instead. It means every library is a liability, because anything that phones home makes the declaration untrue.

What you get back is a release process with far less to go wrong, a data safety form that takes minutes rather than an afternoon of hedging, and no obligation to maintain a backend for a free game indefinitely. For a small title, that trade has been consistently worth it.

Offline is a design constraint, not a feature

Casual games get played where connections are poor: trains, basements, planes, waiting rooms. We build ours to work without a connection at all, which removes an entire category of failure and, as a side effect, removes most of the reasons a session would be interrupted.

The thing to understand is that this is cheap if decided at the start and expensive afterwards, because it shapes how state is stored and what the game assumes it can fetch. That is the same economics as offline sync in business apps, where the cost of retrofitting is the whole argument for deciding early.

What carries over to client work

Shipping repeatedly under our own name is how the release pipeline got good. Each title made the next one faster, not because the games resemble each other but because the launch does: the same signing, the same declarations, the same checks before submission.

That is the part clients benefit from. The first release of any app is where timelines break, and it breaks for reasons that are entirely knowable in advance if someone has been through it recently.