Process
How a project gets from a brief to a build
Seven stages, applied consistently. The interesting part is not the sequence — it is what each stage refuses to skip.
The seven stages
Research
What already exists, what it gets wrong, and whether the data or API needed is genuinely free and correctly licensed. A shared library of vetted resources and previously solved problems gets searched before anything new is written.
Brief
A written specification, usually long and numbered. It states the constraints up front — offline behaviour, permissions, what must never be collected — because those decide the architecture.
Prototype
The riskiest part first. A shader, a save format, a simulation loop. If the hard part cannot be made to work, that is worth knowing before anything is designed around it.
Build
Working, compiling increments in priority order, following the project's own phase and ledger convention. Content is data wherever it can be, so adding an entry never means editing a screen.
Test
Unit tests over the logic, automated accessibility checks over the interface, and schema validation over the content. Several projects also run scripted runtime passes that capture evidence images.
Audit
A separate pass looking for what the build missed: credential scanning, licence checks, privacy review against what the manifest actually declares, and a check that the documentation matches the code.
Release
Signing, device acceptance and store preparation. Anything not verified is recorded as outstanding rather than assumed — which is why several finished projects still say they have no store listing.
Where AI fits
AI assistants are used throughout that sequence — most heavily in research, implementation planning, code analysis and the tedious parts of refactoring. They are development tools, in the same category as a profiler or a linter: extremely useful, and not the thing that decides whether something is correct.
What decides that is the same as it has always been. Tests pass or they do not. The accessibility scan finds violations or it does not. The manifest declares a permission or it does not. A build is signed or it is not. Those checks are what a release waits for.
The honest limitation worth stating: several of these projects have never run on physical hardware, because the environment they were built in could not do that. Every project page says so where it applies, and “pending physical validation” is treated as a real outstanding item rather than a formality.
Workflows in use
Claude Code
Projects designed and built with Claude Code as the primary development assistant, alongside conventional engineering practice.
ChatGPT
Projects built through ChatGPT-assisted workflows — in this library, the Unity games, each developed from a written brief to a running build.
Codex
Projects where OpenAI Codex produced the implementation plan, build reports and progress log kept in the repository.
Cursor
Projects developed inside the Cursor editor, with its assistant integrated into the editing loop.
Rules that outlast any one project
These apply whatever is being built and whoever, or whatever, is helping build it.
Never invent a fact
No fabricated screenshots, download links, store URLs, reviews, ratings, contact details or release dates. A gap is left as a gap and written down.
Never lose user data
Versioned migrations, atomic writes and a backup before any risky change. A save from a newer version is never overwritten by an older build.
Never ship a secret
Keys, keystores and local configuration stay out of the build entirely. A packaged app is a zip file that anyone can open, and is treated that way.
Nothing irreversible without review
No merge, deploy, deletion or published release without a deliberate decision — and a backup first where there is no version control to fall back on.