I wanted to see what AI could actually build. So I gave it a geography game.

I'm not a developer. I can read code, understand roughly what it's doing, and form opinions about structure — but I can't sit down and build a web app from scratch. That was the starting point.

What I did have was an idea: a daily geography game. One 360° Street View panorama per day, same puzzle for everyone, five guesses. Simple. I'd played GeoGuessr for years and wanted something smaller — a one-minute habit, not a rabbit hole.

The real question wasn't whether the game was a good idea. It was: can AI actually build this, or does it just pretend to?

The first version of DailyGuessr was humbling

I started with Claude. Not to write code — I genuinely didn't know if that would work — but to think through the architecture. What do I need? A database of locations. A way to serve one per day. A map for guessing. A score.

Claude walked me through it: Next.js for the frontend, Supabase for the location database, Vercel for deployment. I knew none of these tools. By the end of the first session, I had something running locally that kind of worked.

The DailyGuessr project document went through 31 versions. Not because things kept breaking — though they did — but because the game kept getting better. Version 1 had no mobile support, no streak, no sharing. Version 31 has all of that plus a profile sidebar and stats tracking. The document is the memory. Without it, none of this would have been possible.

The first real wall was Google Maps. Street View panoramas need an API key. The API key needs billing. Suddenly there's a credit card involved, quotas to understand, and a question of what happens if the game actually gets traffic. I spent an afternoon on this that had nothing to do with building the game itself — just configuration, billing alerts, and hoping I'd set up the quota correctly.

What "AI building it" actually looks like

This is the part that surprises people. It's not like typing "make me a game" and receiving a finished product. It's much more like having a very fast, very knowledgeable collaborator who needs to be directed carefully.

I describe what I want. Claude writes the code. I run it. Something doesn't work. I describe what's wrong. Claude fixes it. Repeat.

The skill — and this is the thing nobody tells you — is in the describing. The more precisely I could articulate what was wrong, what I expected to see, and what I actually saw, the faster things got resolved. Screenshots helped enormously. "The modal is covering the map on mobile" is a better prompt than "it looks weird."

The skill isn't coding. It's being a very precise product manager for an AI that never gets tired.

There were frustrating moments. The map z-index bug that took four sessions to isolate. The analytics script pointing at the wrong subdomain — umami.stoop.games instead of analytics.stoop.games — which I only caught because Palette showed zero data for two days. The sidebar that wouldn't stretch to the footer height no matter what CSS I tried.

None of these were the AI failing. They were the normal friction of building software. The difference is that I had a collaborator who could articulate the problem clearly and usually knew the fix.

Then I built five more games

Once DailyGuessr worked, something clicked. The hard part wasn't the technology — it was understanding what I was trying to build. FlagGuessr used the same scaffold, the same tech stack, the same deployment pipeline. It launched the same day as DailyGuessr.

CocktailGuessr came a week later. Then Palette, Bloom, and Sortl — three arcade games with no database at all, running entirely in the browser. Six games in roughly three weeks.

Somewhere in the middle I had the domain cost realisation: each game on its own domain means each game is its own ~$15/year cost. The solution was stoop.games — a hub, with the three arcade games on subdomains (free), and the guessing games keeping their own domains (because their SEO value is real).

What I'd tell someone starting now

The single most important thing is documentation. I keep a project document for every game — updated after every session, tracking what changed, what broke, what the current state of the infrastructure is. Without that, each conversation with AI starts from zero.

The second thing: learn to read error messages. You don't need to understand them fully. You need to be able to copy them accurately and describe the context.

The third thing: build something small that actually works before you try to make it good. DailyGuessr v1 was ugly and barely functional. It worked. Every version after that was an improvement on something real, not a redesign of something imaginary.

---

Six games are live. Two more are in planning. The next post is about FlagGuessr, and why the second game is always easier than the first.

Come back tomorrow. There's a new puzzle waiting. ✿