Journal
Vibe CodingJuly 27, 2026·6 min read

How I Use n8n to Turn a Rough Idea Into a Shipped Feature Faster

Most builders waste hours context-switching between tools. Here's the automation layer that keeps you in flow from idea to PR.

The bottleneck in solo building is rarely the code. It's everything around the code. The spec you have to write, the tasks you have to break down, the context you have to re-establish every time you sit back down after a meeting or a walk.

I started using n8n about eight months ago to close that gap. Not to replace thinking, but to compress the dead time between "I have an idea" and "this thing is actually running."

Here's what the workflow looks like in practice.

The Problem With Freeform Ideas

You get an idea. You drop it in Notion, or a voice memo, or a Slack message to yourself. Then it sits there, half-formed. When you finally come back to it, you spend 20 minutes just reconstructing what you were thinking.

That reconstruction cost is what kills solo momentum. You don't need a project manager. You need a system that does the reconstruction work automatically, right when the idea is fresh.

n8n lets you build that system. And once it's running, you barely think about it.

The Basic Pipeline

The core flow I run has four nodes:

  1. Trigger: A webhook that fires when I submit a form, send a specific message in Slack, or hit a keyboard shortcut via a browser extension.
  2. Expand: An HTTP node calling the Claude API. I send the raw idea and get back a structured spec, broken into context, acceptance criteria, and edge cases.
  3. Store: The output drops into Linear as a new issue, tagged and assigned, with the spec in the description.
  4. Notify: A Slack message back to me with the issue link and a one-line summary of what Claude decided the feature actually is.

Total time from rough idea to triaged Linear ticket: under 90 seconds. I don't touch any of it manually.

Why Claude for the Expand Step

I've tested GPT-4o and Gemini in this slot. Claude wins for spec writing, specifically because it handles ambiguity better. When your input is "add a way for users to archive stuff," Claude will ask the right clarifying questions in its output rather than just hallucinating a confident-sounding spec.

The output format matters too. I use a system prompt that forces Claude to return JSON. That makes the Linear node trivial to wire up. You're not parsing prose, you're just reading keys.

The prompt structure I use is tight. Role, context about the product, output schema, then the idea. Four sections, no fluff. Claude follows it reliably.

Where Cursor Plugs In

Once the ticket exists, I open Cursor and reference the Linear issue directly in my first message. I paste the acceptance criteria from the ticket as my starting prompt. Cursor has the codebase context. The ticket has the product context. Combined, the first generation is usually 70-80% of what I actually ship.

The n8n pipeline feeds Cursor better inputs. That's the real leverage. Garbage in, garbage out applies hard to AI-assisted coding. A well-structured spec means fewer correction loops.

Automating the Review Cycle

I added a second n8n flow for after the PR is opened. It triggers on a GitHub webhook, pulls the diff, sends it to Claude with a review prompt, and posts the output as a PR comment. It's not replacing a real code review. It's catching the obvious stuff so I'm not shipping dumb errors alone.

Things it catches regularly:

  • Missing error handling on async functions
  • Hardcoded values that should be env vars
  • Return types that don't match the spec
  • Functions that got too long during iteration

It flags, not blocks. I decide what to fix. But having a second pass that costs me zero time has genuinely improved what I ship.

The Make.com Version

If you're on Make.com instead of n8n, this is all buildable. The node structure is the same conceptually. Make's HTTP module handles the Claude API call fine. The main difference is that n8n gives you more control over error handling and retry logic, which matters when you're chaining multiple API calls. For simple flows, Make is faster to set up.

I started on Make. I moved to n8n when my flows got complex enough that I needed to run custom JavaScript mid-workflow without hacking around it.

The Exact Prompts and Node Config I Actually Use Here's the Claude system prompt I use in the expand node, verbatim: You are a senior product engineer helping a solo developer turn...

This section is for Inner Circle members.

Get the full breakdown, exact prompts, and step-by-step workflows.

Unlock with Inner Circle →

The exact prompts, node configs, and the PR review flow setup are all in the Inner Circle breakdown. If you're building solo and want the copy-paste version, that's where it lives.


Keep building

KZZY

Written by KZZY

Founder and CEO of Vaylo Studios. He builds AI-powered software products like Pulse and runs the Inner Circle, teaching operators to build like a giant with a small team.

Inner Circle

Build with people doing it.

Weekly live sessions, a full AI build curriculum, premium tutorials, and a community of operators and builders shipping real products. $47/month.