When your team is distributed and lives on Zoom, a watercooler call where you just hang out is a welcome break from work-only meetings. We would usually find a quick game everyone can jump into — Codenames, Skribbl, etc. We where looking to try a new, GeoGuessr-style game. The catch: it capped out at three players, there were about eight of us, and someone would have to put in a card to open more seats. 🫠

Working in SaaS, you look at games like these and the reflexes kick in: this isn’t hard to build. The APIs are there. The mechanics are simple. So I wrote myself a note: build a clone of a world-seeking game and open-source it. Then the note sat in my to-do list collecting dust, the way those notes do.

It came back to life when i decided to mazamise my claude code subscription, I had it to try the new 4.8 model and wanted to see what it can do in a day. Velocity was the name of the game or sI thought.

The thing I actually learned

I went into this thinking I’d learn something about velocity. I did. But the real lesson was what impact this has had on the order things happen in.

For years, the process looked like this: you research and define the scope so you have something to hand off to a designer. Then, you go back and forth on wireframes, test them, gather feedback, and iterate until the designs are clean enough for FE to build a clickable prototype. Only after all of that do real users finally get to try it and tell you what’s broken.

It is a massive loop just to get someone to play with an idea. Clicking through a Figma prototype isn’t the same as testing a functional product. You discover so much more about what’s missing by actually using it—but building functional prototypes has always been too expensive because it requires running through the entire product cycle and looping in engineers.

Building this game, that loop turned inside out.

With AI, the prototype is the cheap part now. I had something people could actually click through and give feedback. The tight feedback loop moved all the way up to the front, into the ideation phase, and I got to scope backwards from a thing that already existed. You discover what’s missing by using it, not by imagining it in a doc.

One shots is a great trick but you learn nothing

My first instinct was not to zero-shot the entire game.

You can do that once as an experiment, and it’s a fun party trick. But whatever falls out the other end leaves you with zero context. You don’t know how it’s wired, where the landmines are, or why it made the choices it made.

I’d rather be in the loop as it’s starting so you have a sense of what decisions are being made and you can help guide the process. Worry about stepping away afterwards when you need to scale and reduce maintenance overhead.

Write the happy path like you’re telling a story

Before any of the real building, I wrote out the game as a story.

I literally dictated it — talked through one clean playthrough start to finish so the AI understood the mechanics the way I did.

Everybody joins. Everybody hides first: you click around a map, and because you might not recognize a spot, you use the street view to see what you’re actually picking. You confirm your hiding place. Once everyone’s locked in, the host starts the round.

Then it goes one player at a time. We show that player’s hidden spot to the room, the map wipes to a blank canvas, and everyone drops a pin guessing where they are. Closest pin wins the most points. The whole trick is that when you hide, you see exactly what everyone else will see, and they have to guess from that one view without digging around.

That’s the whole game. Simple. But the magic of writing out the happy path is what comes next: I handed it to the AI and asked it to find the gaps. It came back with the edge cases and the questions I hadn’t thought to ask, and I got to answer them on my terms instead of tripping over them later.

Play it, fix the papercuts, repeat

Then Claude Code went off and built it, and I did the most important thing: I played it.

Immediately the papercuts showed up. I’d drop a pin and there’d be no street view to orient me. As a player, you don’t want to fight the map. You want to drop a pin and have it be smart enough to do the right thing. So I noted it, fixed it, and kept going. I wasn’t adding features yet. I was just asking one question over and over: did it work, and if not, where’s the friction?

Once the happy path felt good, the mental model switched. Now I could step back and think about what would make this genuinely better. Mobile, and whether the whole thing was responsive. UI that didn’t hurt to look at — avatars, little animations when people are picking, a count of who’s guessed and who’s left. I even realized a multiplayer game needs a single-player mode so people can practice.

The pattern that worked was picking one pillar at a time and running it all the way through the loop. Pick a thread, play the game, find the friction, tweak, ship it, move to the next. It sounds like a lot because there are so many features, but most of these were one or two prompts I could flesh out in fifteen minutes. It’s an iteration game.

Then a polish pass — colors, button states, the basics. Not fully themed, but enough to enjoy. And because I wanted to see if this could be more than a prototype, I had the agents write the Docker files so I could host it on my own Coolify instance. Deployment, secrets, the boring parts, done fast. That’s the part that still surprises me.

So where do I actually fit?

Here’s the thing the AI couldn’t do for me: tell me if the game was any good.

The code can be correct and the game can still be no fun. Only a person playing it can feel that. Same goes for anything you build. If it’s a productivity app, the AI can confirm the code is right, but it can’t tell you whether you feel like you’re saving time, or whether this is even worth investing in. When the answer is no, you’ve got work to do that the AI can’t do for you.

I want to be clear about the ceiling here, too. Getting to a fast, playable prototype is solved. Getting from there to something truly production-ready — hardened, scalable, safe to put real users on — is still hard, and it still takes domain knowledge the AI doesn’t have on its own. That gap is exactly where you have to stay sharp.

That’s why I think you have to struggle at the beginning. You have to ride the loop while you’re setting something up, because you’re the one who has to feel the problems and learn where all the soft spots are. The easy move is to let the AI do the thinking and check out. But that’s how you stop being able to make the call when it counts.

As a project grows, you start asking the better questions: what doesn’t need me anymore? What can I automate or hand off? What needs real research that an agent can handle while I’m elsewhere? At the start, you’re not above the work. You’re in it, building alongside the agent. The skill is knowing when to step out, and where you’re needed next.

Was it worth two dollars?

I set out to avoid a $2 fee and I spent a full day building, then trickled in updates all week. By any honest accounting, that’s way more than two dollars of my time.

I’d do it again without thinking. The point was never the two dollars. It was getting to live in a world where an idea that would have died in my to-do list can become a real, playable, deployed thing in a couple of days.

None of these ideas are new, and the code probably isn’t something you’d copy. With AI you don’t need to copy it anyway. What I’d want you to take is the workflow: write the happy path, let the AI find your gaps, then play your way forward one pillar at a time, staying in the loop the whole way.

It’s out there and open-sourced, so go play it. And next time something stalls in your to-do list because it’d take too long — try asking how far you could get this weekend instead.

Here’s a quick playthrough:

🎮 Grab the code: github.com/heyivanvilla/world-seek