The instinct when you have an idea is to start building. Open a new repo, pick a stack, start scaffolding. I've done this enough times to know how it ends — two weekends in, you discover the idea wasn't quite right, or something already exists that does it better, or the thing you actually wanted to build was different from what you started.

So before any of that, I've started running ideas through an exploration session first. Here's what that looks like.

The session that kicked this off

I wanted to build a restaurant tracker. Me and my girlfriend, a shared map of places we want to try, have been to, loved, avoid. Simple enough — I had a rough stack in mind and was ready to start.

The first thing I did was ask: does this already exist?

It does. It's called Beli. Shared lists, personal ratings, want-to-go, map view, two people can follow each other and see ratings. It's almost exactly what I had in mind.

That could have been the end of the session. Instead it was the beginning.

What happens when the answer is "use this instead"

Getting redirected to an existing tool isn't a failure. It frees up the exploration. You stop thinking about the mechanics of what you were going to build and start asking: what does this tool miss? Where does it fall short?

My girlfriend tried Beli the same evening. Her reaction: "it's more like social media than food itself — I don't care about other people and their scores."

She wasn't giving feedback on an app I'd built. She was describing a gap. Beli optimised for engagement — following strangers, trending restaurants, social feeds. The people who just want the tracker, the private utility, had nowhere to go.

That's a real product insight. And it came directly from the "does this already exist?" step returning an answer.

Following the thread

From there the exploration opened up. What would a private-first version look like? What's the actual social graph here — not strangers, but the groups you already have?

The dinner crew who coordinates entirely through WhatsApp polls that disappear. The girlfriend. The friends from home you want to take somewhere good when they visit. The football team deciding where to go after a match.

Each group has its own context. A shared map per group — their want-to-try overlap visible, a quick vote, the history building up over time. Not a new social network. A food layer on top of the relationships you already have.

The one-liner that emerged: WhatsApp on Google Maps.

That's the kind of clarity you're looking for. When you can say what something is in five words, you understand it well enough to build it — or to decide not to.

The outputs

By the end of the session I had:

• A scoped concept with features cut to what's actually necessary
• Five shippable chunks in order, starting with just the two of us
• An honest assessment: what's strong, what's weak, what needs scale to work
• A pitch short enough to send on WhatsApp
• A prototype prompt ready to paste into Bolt.new
• A rough cost estimate at three scales

None of that required writing a line of code.

What the workflow actually looks like

The rough sequence:

1. Clarify the core need. What problem, for whom. One sentence if possible.
2. Does this already exist? Search before building. The answer either saves you weeks or redirects you to something better.
3. Sketch approaches. App vs web vs no-code vs existing tool. Effort per approach, stack fit.
4. Feature matrix. Must/Should/Could/Won't. Forces you to be honest about what's core and what's scope creep.
5. Follow the threads. The most interesting ideas in this session came from questions asked after the original idea was answered. Don't cut it off early.
6. Rate it honestly. Personal value, novelty, effort vs reward. If you can't articulate why it's worth building, that's useful information too.

The goal isn't to kill ideas. It's to understand them well enough to decide whether to build, what to build, and in what order — before any of that is decided by the code you've already written.