A few weeks ago, NearbyGame was something completely different.
It was not a game. It was a place to find badminton and table tennis venues nearby, something between Yelp and Meetup. The idea sounded reasonable: help people discover places and connect to play.
But something felt off. I did not have the energy to manually collect venue data, and there is no clean free source for it. OpenStreetMap helps, but a lot of venue information is missing, stale, or simply wrong. Very quickly, I realized I was signing up for an ingestion pipeline with a lot of manual intervention.
More importantly, it did not feel exciting to build.
So I paused. And instead of forcing execution, I started using AI to think.
Step 1: Realizing the Problem Was Not Execution
At first, I thought maybe I just needed to push harder: collect more data, improve SEO, add more features. But after a few conversations, with AI acting as a sounding board, it became clear that this was not an execution problem.
It was a problem selection problem.
The original idea hid a lot of constraints:
- It required manual venue data.
- It implied a two-sided marketplace: players and places.
- It had low engagement frequency because people do not play every day.
- It depended on network effects too early.
That is a hard place to start. AI did not give me the answer, but it helped me see the structure of the problem more clearly.
Step 2: Breaking the Idea Down
Instead of asking, "How do I fix NearbyGame?", I started asking, "What part of this idea actually matters?"
Through iterative conversations, I decomposed the concept into three pieces:
- Nearby -> proximity
- Game -> interaction
- People -> connection
Then I questioned each assumption. Do I really need real-world venues, scheduling, or coordination? The answer was no. Those were simply the hardest parts of the original idea.
Step 3: Reframing the Idea
That was the turning point. Instead of asking how to help people organize games in real life, I asked a different question:
What if people are already inside a shared experience, and connection happens naturally?
That immediately opened a different design space. The product no longer had to coordinate people first. It only had to create the conditions for a meaningful encounter.
Step 4: From Coordination to Encounter
The old idea required effort before anything good could happen:
- Find a place.
- Find a time.
- Find people.
The new idea removes most of that. You open the app, start walking, and occasionally encounter someone. Only then do you decide whether you want to interact.
Old loop -> New loop
- Plan first -> Experience first
- Coordinate people -> Discover people naturally
- Logistics-heavy -> Low-pressure and ambient
NearbyGame is now a quiet walking experience where you might meet someone. You start in a foggy world, walk forward, explore abstract cities, and accumulate distance over time. There is no detailed map and no urgent destination. Just progress.
And sometimes you see another player. You do not know them. You do not have to talk. You can ignore them, acknowledge them, or send one simple signal: Game? If both agree, you jump into a small shared game and then continue the walk.
Step 5: Designing for Single-Player First
This was one of the biggest lessons. The original idea only worked if multiple users showed up at the same time. The new version works with one user.
That changes everything:
- No dependency on immediate network effects.
- No cold-start problem.
- No need for growth before value exists.
AI kept reinforcing the same principle back to me: make it meaningful for one user first. That advice sounds obvious in retrospect, but it completely changed the product direction.
I actually love this version of the idea. To be honest, I was having fun while testing the app, which was not true in the same way for the venue-search version.
Step 6: Using AI to Go From Idea to Structure to System
AI was not just helping me brainstorm. It helped me move from intuition to structure.
Clarifying Constraints
- What to avoid: marketplaces, scheduling, coordination.
- What to focus on: a solo loop, lightweight interaction, calm pacing.
Defining Architecture
- What platform to start with.
- What technology made sense for frontend, backend, and cross-platform delivery.
- What telemetry mattered without burning server load.
- What security concerns deserved early attention.
Breaking Work Into Systems
- World rendering
- Session system
- Progression system
- Map system
I even used AI to help generate project scaffolding and reusable operating context: a project philosophy file, modular agents, reusable skills, and a product narrative. That turned a vague idea into something I could actually build instead of just admire.
Step 7: Building the First Version
Instead of jumping straight into a full 3D engine, I chose a lighter path: web-based rendering, a simple foggy road, and abstract city nodes. The goal is not graphics fidelity. The goal is to answer one question first:
Can I create something simple that people want to come back to?
That constraint kept the first version honest. It forced me to focus on mood, pacing, and repeatability instead of wandering into technical vanity.
Step 8: Adding Meaning Through Progression
One small feature made the experience feel real: landmark discovery and area exploration.
As you walk, your distance converts into lightweight progress signals such as "you have explored 6.5% of Washington State" or "you have seen Space Needle". It is abstract, but motivating.
- Direction without pressure
- Progress without hard goals
- Scale without a lot of complexity
This is the point where I started to feel genuinely excited. While building the game, I learned more about a state, its cities, and its landmarks. The experience started to feel educational in a gentle way, while still staying calm and relaxing.
What I Learned
This pivot clarified a few principles for me:
1. Do Not Force Ideas
If something feels heavy for a long time, it usually is.
2. Remove Dependencies
The more your product depends on other people showing up before it becomes valuable, the harder it is to start.
3. Build for One User First
Then layer social behavior on top, not the other way around.
4. AI Is Not Just for Coding
For me, AI has become a thinking tool for breaking down ideas, challenging assumptions, and exploring alternatives before implementation gets expensive.
5. Speed Matters
I went from a stuck idea to a new concept, a clearer system, and a working landing page in a very short time. That kind of iteration speed changes what feels buildable.
What's Next
Right now, NearbyGame is still early. The next step is simple: finish the first MVP and ship it.
Then the real test begins:
Does this feel like something I want to come back to?
I am actually very close to the MVP, so stay tuned. I expect the interesting part to start once the product is live enough to learn from real behavior instead of only from my own taste.
Final Thought
NearbyGame did not fail. It evolved.
And the biggest shift was not technical. It was moving from organizing people to creating a world where connection can happen naturally.
If you are building something and feel stuck, try this: do not ask, "How do I build this?" Ask, "What part of this idea is actually worth building?" That is where the real pivot begins.