Building Addictive Web Games with Claude Opus 4.7: A 2-Day Solo Dev Case Study

A senior developer shipped a polished, playable web game at downtime.partridge.works in roughly 48 hours. No team. No pre-existing engine. The build was driven by Claude Opus 4.7 working alongside the developer in a tight prompt-review-iterate loop rather than a “generate it all at once” approach. We dug into the workflow because the interesting part is not the speed — it is the collaboration pattern.

You can ship a small web game in a weekend with any half-decent stack. What changed in early 2026 is that the bottleneck shifted from “can I write this code” to “can I describe what I want clearly enough.” Opus 4.7’s 1M-token context window means the model can hold the entire design doc, the current codebase, and a running list of decisions in working memory across days of sessions. That is the unlock most solo devs are still underusing.

The two-day timeline

Day one was spent almost entirely on planning and the core game loop. The developer wrote a one-page design brief — what genre, what the player does in the first ten seconds, what makes them come back — and pasted it into Claude as the seed. From there the workflow was: ask Claude to propose an implementation plan, push back on the parts that felt overengineered, ask for a simpler version, then approve and execute.

Code generation happened in chunks of a single concern at a time: input handling, then collision, then a basic enemy spawner, then the scoring loop. Each chunk got tested in the browser before the next prompt fired. By end of day one, the prototype was playable but ugly.

Day two was polish. Particle effects, screen shake, sound design, a basic title screen, and the difficulty curve. The developer reported that the second day was where the iterative workflow paid off most — the cost of “try a different juice effect” dropped to maybe two minutes of round-trip prompt time, so they tried dozens of variations they would never have hand-coded.

Iterative plan-feedback prompting in practice

The pattern this developer used — and that you can copy directly — has three moves.

1. Plan before code, every time. Instead of “build me a snake game with a power-up system,” you ask Claude to write the plan first. What files will exist. What functions go in each file. What data structures hold state. What the failure modes are. You read the plan, push back on anything that feels off, and only after the plan is good do you ask for code. This sounds slow. It is dramatically faster than debugging a 400-line one-shot generation.

2. Constrain the diff surface. “Add a particle effect when the player gets a coin” is a bad prompt because Claude does not know where particle code should live or whether you already have a particle system. “Add a particle effect when the player gets a coin. Touch only src/effects/particles.ts and the coin pickup handler in src/entities/coin.ts. Do not introduce new files. Match the existing emitter pattern” is a good prompt. Specificity about which files can change is the single highest-leverage habit.

3. Test in a real browser between prompts. This is the part most solo devs skip. Type-checks pass, the code reads fine, you accept the diff and move on. Then on day two you realize the collision detection has been silently wrong for six hours. Open localhost. Click around. Diff what you see against what you asked for. The model is a fast collaborator, not a careful one.

The developer also mentioned a less obvious habit: keeping a DECISIONS.md file in the repo that gets pasted into every new Claude session. It captures the why behind early choices — “we picked Phaser over plain canvas because X” — so the model does not quietly relitigate settled decisions on day two. With a 1M context window you can paste the entire repo, but a clean decision log is still worth more than raw code because it tells the model what not to change.

What this signals for solo developers

The story is not “AI replaces developers.” Senior judgment is doing the heavy lifting at every step: deciding what to build, recognizing when a generated approach is overengineered, knowing what “juicy” feels like in a game without having to be told. The model is a fast pair programmer who has read every game dev tutorial ever written and has zero ego about being told to redo it.

What is actually new in 2026 is the ratio. A weekend used to mean a barebones prototype. With the plan-feedback loop running on a 1M-context model, the same weekend produces something that has taste — the small interactions that make a game feel alive. Those used to take weeks of iteration because each iteration was expensive. They are cheap now.

If you are a solo developer who has been waiting for AI tools to be “good enough,” they crossed that line. The remaining bottleneck is whether you can describe what you want with the precision of an art director rather than the vagueness of a customer.