What indie puzzle game development actually looks like, solo

What "solo" actually means day to day

Solo development doesn't mean one person doing a whole studio's job at a slower pace — it means every role a studio would normally split across people (design, implementation, testing, cutting features) collapses onto the same judgment, in the same day, with no second opinion built into the org chart. That has a real cost: there's no one else in the room to catch a blind spot before a playtester does. It also has a real benefit: there's no translation loss between "what the designer meant" and "what the engineer built," because they're the same decision made once.

Where AI genuinely helps, and where it doesn't

An AI-assisted production workflow changes the economics of solo development without changing what solo development actually is. It helps with the parts of the job that are mechanical once a decision has been made — scaffolding code, iterating on an already-chosen approach, catching obvious bugs faster than a single pair of eyes would alone. It does not help with the part that defines whether a puzzle game is any good: deciding whether a mechanic is fair, whether a level is actually fun to solve, whether a difficulty spike is earned or just annoying. Those calls still get made by playing the thing and watching someone else play it, the same process described in what actually goes into designing a digital puzzle game. AI speeds up getting to the point where that judgment can happen; it doesn't replace the judgment itself.

Scope discipline as a design tool

For a solo team, scope isn't a project-management afterthought — it's one of the main design tools available. Every feature added is a feature that has to be built, tested, and maintained by the same one person who's also deciding whether the core puzzle mechanic actually works. Cutting scope isn't settling for less; done well, it's how a small puzzle game ends up feeling more focused than a larger one, because every remaining system got enough attention to actually be finished rather than merely present. The failure mode to watch for isn't "too small a game" — it's a game whose scope quietly outgrew what one person's testing and iteration time can actually cover.

Player testing and launch uncertainty

Solo development doesn't remove the need for real playtesters — if anything it makes their feedback more load-bearing, since there's no internal team providing a second read on whether something is confusing. It also means launch uncertainty is carried personally rather than spread across a studio: there's no marketing team, no publisher relationship, no guaranteed audience waiting on day one. That's simply the honest shape of solo development, not a problem to be hidden — it's part of why the first Solobit Games title has no release date yet, and won't have one until the design and testing loop says it's actually ready.

How this connects to Solo + Bit

This note is the day-to-day, practical version of the studio story told in more detail on Approach — the "Solo + Bit" idea in action: Solo makes the calls that require taste and judgment, Bit accelerates the mechanical work those calls create. Neither half does the other's job. An AI-assisted workflow that tried to make design judgment calls on its own wouldn't be solo development anymore, and solo development without any tooling help would just be slower — the combination is what makes a small puzzle studio's pace realistic without pretending the human judgment part can be automated away.