I've been asked many times about how I come up with ideas, how I decide what's worth building, and what my "framework" is for getting started.

The truth is – I don't really use a framework.

What I do have is a system. One that lives in my head, was built through repetition and intuition, and has evolved over decades of building things fast, throwing most of them away, and keeping only what's worth refining.

Some people might call it instinct. I call it experience layered with systems thinking.

And in this post, I want to show you how I work through new ideas – not with a whiteboard or a Notion template, but with a long conversation.

This isn't "vibe coding". This is vibe brainstorming – and it's how I test ideas, challenge assumptions, and break down complex problems before executing, presenting, or writing a single line of code.

Step 1: It starts with a spark

Most of my ideas start the same way: a visual spark, a problem I face, or something I see that sets off a cascade of thoughts.

Could be a landing page. Could be a badly designed signup flow. Could be someone talking about a business they wish existed.

Once something clicks, I move fast. But not recklessly – I jump into a mode where I can explore it thoroughly.

That's when I open ChatGPT.

Step 2: Structured chaos

The first thing I do is tell ChatGPT the core idea. Then I list the specific aspects I want to dive into:

  • target user
  • pricing model
  • technical stack
  • project architecture
  • user experience
  • key features
  • potential challenges
  • distribution channels
  • ...

This becomes a sort of agenda for the brainstorming session.

Then we go deep. One by one.

I ask questions, share thoughts, and request pushback. That part's important – I want the AI to challenge me, not just echo back. I ask it to highlight contradictions, suggest alternatives, or poke holes in my logic.

Every time we "close" a topic, I ask ChatGPT to summarize it into a Markdown doc. Those summaries pile up quickly: one for UX, one for data modeling, one for monetization, etc.

This part usually takes hours and occasionally might even span over a few days. We go through every single detail and leave no stone unturned.

By the end, I've got a full research dump ready to feed into a custom GPT or a project doc.

Step 3: (If it's a software project)

If the idea survives this gauntlet of questioning and reframing, I'll move on to Claude to turn the notes into a PRD (product requirements doc).

From there:

  • I load the PRD into Cursor with Claude 4.0 Sonnet (or Opus for large projects).
  • I use my Taskmaster MCP to break it into dev-ready tasks.
  • I work with Cursor to tackle tasks one by one.

This is where past prep pays off. I have:

  • A library of code snippets I've already documented and reused.
  • A custom design system, fully specced and AI-readable.
  • Clear standards that help AI produce outputs that match my style, preferences, and architecture.

So it's not "let's see what the AI generates". It's more like working with an extremely fast junior dev who already knows your whole stack.

I don't let the AI make architectural decisions. I watch it like a hawk and review its code before approving it. I also ask it to justify every function and every coding decision it's made (this usually results in cutting the code by at least 20%).

Vibe coding

This works for me

This isn't meant to be prescriptive. I'm not saying you need to do things my way.

But I am saying that most productivity advice is garbage unless it helps you build a system that works for how your brain actually functions.

For me, writing things down isn't about creating a second brain – it's about clearing out mental RAM so I can think more clearly.

I don't use frameworks. But I do follow internal SOPs that are second nature by now (one of them is here.)

And I don't spend time wondering if a problem is too big. I just start breaking it down:

  • What's the core problem?
  • Who is it for?
  • What's the simplest version?
  • What are the dependencies?

Whether it's a product idea, a tech problem, or a business model – if you can decompose it, you can evaluate it.

Final note

There have been times I ignored my instinct. Times I didn't move fast.

One example is Tradologics. I waited too long, got caught up in trying to make it perfect, and the end result wasn't what I've set up to achieve. I'll write more about that in a future post.

But what I've learned is this: intuition is a muscle. You build it by thinking, building, evaluating, and repeating. If you do that long enough, you don't need a playbook.

You just need a spark – and a few hours to brainstorm the hell out of it.