# The n8n bug that took three tries to find (and the free workflow it broke) > Source: > Published: 2026-06-28 06:43:36+00:00 I built a free n8n workflow that writes your launch content for you. It broke three times before it worked, and the third break is the only part of this post worth reading. Every time I ship a new digital product, I write the same five things: a short blog intro, a LinkedIn post, an X post, an Instagram caption, and a launch email. Same structure every time, different product. The kind of task that's boring enough to automate but annoying enough that I kept putting it off. So I built **Launch Content Pack**: an n8n workflow that takes one product description and generates all five, using an LLM node wired up with Claude Code on the customization side. It's free, it's on Gumroad, and the JSON is the whole product — open it, see every node. There are. I checked before building this, because there's no point shipping a workflow that already exists for free somewhere else. What's actually missing from most of those templates: nobody validates the nodes. A huge chunk of free n8n templates floating around were generated by someone (often an LLM) guessing at node types and parameters, and they quietly break the moment n8n ships a version update. I used [n8n-mcp](https://github.com/czlonkowski/n8n-mcp), a free MCP server, to confirm every single node type, version, and parameter against n8n's actual schema before writing any JSON. No guessing. That sounds like a small difference. It's the reason this post exists. I tested the workflow in n8n Cloud. Two nodes ran clean — green checkmarks, no errors. Then the Code node that's supposed to take the LLM's output and split it into five labeled fields threw: ``` Cannot read property 'text' of undefined ``` My first guess was wrong. I assumed the LLM node's output field was named something other than `text` — `output` , maybe, or `response` — and that I just had the wrong field name in the Code node. Reasonable guess. Also not the actual bug. Here's what was really happening. The OpenAI Chat Model node had **Response Format set to JSON**. When that setting is on, the Basic LLM Chain node doesn't hand you raw text to parse yourself — it parses the JSON *for* you and dumps the keys straight onto the item, at the top level. So instead of `item.json.text` containing a JSON string I'd need to parse, I had `item.json.blog_intro` , `item.json.linkedin_post` , and so on, already sitting there as separate fields. My Code node was looking for text to parse. There was no text. The data I wanted was already exactly where I wanted it, just one level up from where I was looking. Nobody tells you this. It's not in the node's description, and I didn't find it until I asked n8n-mcp to pull up a real production template that uses the same response format and looked at how it actually structures its output. Pure trial-and-error would've taken a lot longer than checking a real example. Fixed version reads defensively: check if the five fields are already at the top level, and only fall back to parsing raw text if they're not. Works either way the LLM node decides to behave. That fix, plus the two smaller bugs before it, are written up in the kit's GOTCHAS.md with the real error messages and the real cause. Not a "here's what could theoretically go wrong" list — the actual failures from this actual build. One credential required: an OpenAI API key. n8n Cloud's free trial currently throws in some free OpenAI credits, so you can test the whole thing without paying for API calls. Grab it here: [https://ibrh96.gumroad.com/l/zbmpzn](https://ibrh96.gumroad.com/l/zbmpzn) I'm weighing a paid follow-up: the same idea but built around one specific niche, with a filled-in build-brief instead of a generic prompt. Genuinely undecided on which niche is worth the time. If you try the free one and have an opinion, the comments are open.