n8n Seoul Meetup 3rd Recap: Three Real-World n8n Adoption Cases
Who this is forHR managers and IT leads preparing an AX project, and office workers who have to bring AI into their work with no company support.
On Friday evening, September 4, 2026, I wrote up the talk from the third n8n Seoul Meetup, held at Learning Spoons in Gangnam. I kept the diagrams and memes from the 48 slides as they were, and filled in the spoken parts of the talk with written text. The core is the trial and error from adopting n8n at three companies. If this post helps you avoid one of the same mistakes, it has done its job.
Contents
- Case 1. Hospital Expense Receipts
- Case 2. Adoption at a Large Korean Company
- Case 3. One-Person Business
- Lessons by Case
- My Conclusions from the Three Cases
- Takeaways by Reader
- Q&A
Event Info
| Item | Details |
|---|---|
| Event | n8n Seoul Meetup 3rd - After-Work Networking (Luma page) |
| Date and time | Friday, September 4, 2026, 19:00~22:00 |
| Venue | Learning Spoons in Gangnam, Seoul (Gangnam is a Seoul district; Luma listed only “Gangnam-gu,” and the exact address was sent individually to approved attendees) |
| Size | 40 people, free, approval required (registration closed) |
| Organizer, sponsor | Organized by DataPopcorn (a Korean organizer), sponsored by n8n Community |
The program had four segments.
| Time | Content |
|---|---|
| 19:00 | Check-in and welcome networking |
| 19:30 | Keynote: latest n8n news, review of n8n Fest 2026, live demo of n8n CLI and native MCP support |
| 19:50 | Case talk (Im Jeong): How companies adopt and run n8n |
| 20:10 | After-Work Networking, wrap-up at 22:00 |
This meetup wasn’t an intro n8n class. It was designed as a place for people who had built workflows themselves to share experiences and problems. My session was the slot on “real consulting cases showing how companies adopt and run n8n.”
On-Site Sketches
A wall banner reading Seoul Meetup over the Gangnam Station night view, and an entrance X-banner with connected node shapes, greeted attendees.
The entrance table was covered with n8n stickers (noderunner, bot boss, AI AGENT ON BOARD, low code high vibes) and DataPopcorn business cards. The long table by the window had 40 servings of cola and snack bags lined up.
Dinner was burgers. A classic for a Friday after-work meetup.
At 19:50, after the keynote, it was my turn. “n8n Is Open for Business” appeared on screen, and I started the 20-minute talk.
The title slide is a photo of a collapsed building. I’ll explain later why I opened with that meme. The short answer: this year people around n8n kept saying “n8n is finished,” but the n8n I saw on the ground was open for business.
Speaker Introduction
I’m Im Jeong, an eight-year data scientist who teaches courses and does consulting under the name BuildnWrite. I wrote n8n Does It All, and Claude Does It All comes out in October. My courses on n8n and AI workflow design have reached 1000 cumulative students with a 4.9 rating, and I’ve given more than 40 lectures for companies including Samsung C&T and Samsung Electronics. Earlier talks include “Why Product Teams Love A/B Testing” and “Claude Code and the Direction of Data Roles.”
Today’s Topic
Today’s story is one thing. I’ll introduce companies in the middle of adopting n8n, and share the trial and error I went through there along with my own experience.
I checked the application forms. Of 39 attendees, 20 were n8n beginners, and the most common main use was internal business automation, with 23. So instead of explaining nodes one by one, I focused on “when and how n8n gets used at companies.”
In 2025, n8n Was the Trend in AI Agents
n8n ranked first in the 2025 JavaScript Rising Stars (risingstars.js.org/2025). It was the year n8n was hottest alongside the AI agent craze. In June 2026, I published n8n Does It All with Lee Inyoung, riding that same wave.
Claude, the Natural Disaster
Right after the book came out, Claude Code arrived. I call it a natural disaster. Code comes out of a single “build it” in the terminal, so the claim spread in the community that no-code tools are pointless and n8n is dead. The collapsed-building photo on the cover captures that mood. As the book’s author, the expression in the interview meme matched exactly how I felt.
Even so, I keep using n8n. Today’s talk is a chance to prove why, using three cases.
Three Corporate Adoption Cases
| Case | Organization | What |
|---|---|---|
| 1 | General hospital finance team | Automating expense receipts |
| 2 | Business support at a large Korean company | Internal business process PoC |
| 3 | One-person business (me) | Automating my own work |
The three cases connect in order. I applied what I learned at the hospital to the large company, and what I learned at the large company to my own business.
Case 1. Hospital Expense Receipts
Project Background
A request came in from the finance team of a general hospital for mentoring. The ask was clear: they wanted to build part of their internal system in n8n, with non-developer staff building it directly. About 20 people attended, including the hospital director, and we ran six weeks of development and mentoring.
The work they wanted to automate had three parts:
- Receipt logging: Reading paper receipts and organizing them into line items
- Approval line organization: Deciding approvers based on the job title hierarchy
- Approval drafting: Submitting to the existing approval system
Requirements
The hospital wanted three things:
- Everything handled through chat (Chat node)
- Each step built as multi-agent
- A system that non-developers can operate
They wanted all three parts treated as one block and fully automated.
When a Decision Is Needed
Twelve people in the meeting room are looking at me. “Can this work?” Facing that look, a consultant has to make a call. It can be made to work. The problem is what happens after it works. Below is how I handled each of the three requirements.
Problem 1. Handling Everything Through Chat
n8n’s Chat node makes file uploads very simple, so at first everyone thinks, “Chat can do it all.” Here’s what happens when you build it:
- You have to request specific input precisely. Even if you say “please upload receipts,” people send several photos or the wrong file.
- With many files, you need separate processing, plus separate logic to store them on a server.
- You have to manage login and chat history.
In practice, it becomes a huge chatbot-building problem. This is the moment a receipt-processing project turns into chatbot platform development.
Fix 1. Switch to a Survey
A chatbot feels flexible from the user’s side, but AI responses are slow. And the more autonomy you add, the more cases the software has to handle.
So I dropped the Chat trigger and switched to the On form submission trigger. Users upload and submit receipts into fixed fields, like a survey form. With fixed inputs, the downstream processing became simpler. Users get a little less freedom, but the system becomes much more predictable.
Problem 2. Building Every Step as Multi-Agent
The diagram above is the structure we actually built. Under an orchestration agent sit the receipt-recognition agent, the approval-line declaration agent, and the approval-drafting agent, each holding its own model. It looks impressive.
One fact: even raising the success rate of a single AI agent from 95% to 99% is very hard. Yet this structure expects three agents chained together to run smoothly. If each one is at 95%, chaining three multiplies the success rate and it drops. One wobble anywhere shakes the whole thing.
Fix 2. Dropping the Multi-Agent Design
I removed all the agents. The final workflow is as simple as shown above:
- Trigger: On form submission
- Task: HTTP Request to call an OCR API, Edit Fields to clean up, Basic LLM Chain to structure the output (Gemini model + Structured Output Parser)
- Target: Add one row to Google Sheets
Simplifying to plain OCR gave us both speed and accuracy. During consulting, I compared three OCR models with 100 runs each. Reading receipts with a general-purpose LLM was slow and accuracy was unstable, while a document-specific parsing API got all 100 runs right in around 4 seconds. That result was the basis for the decision “one OCR step instead of three agents.”
Problem 3. A System Non-Developers Can Run
The third requirement couldn’t be solved with technology. The actual situation was this:
- There’s no main developer.
- The approval baseline is a job title hierarchy problem, and it existed only as a table, with no systematic definition.
- When job titles changed, there was no designated process to update and manage the table.
- The data server (S3) storing everything had no management policy.
- AI agents keep advancing, but no one was assigned to adjust the structure and prompts to keep up.
Building a workflow in n8n and keeping that workflow running a year later are completely different jobs.
Lessons (Hospital)
- More nodes don’t make a better workflow. They only add more points to manage.
- Before introducing AI, clean up data management (approval lines).
- This isn’t an argument against n8n. Without development skills or staff to run it, any tool will struggle.
In short, the problem isn’t n8n or Claude. Adoption and operation are only possible when someone owns the system as its manager and understands the design. I especially want to stress this for HR managers. The success or failure of an AX project depends less on tool selection and more on drawing “who will run this?” into the org chart.
Case 2. Adoption at a Large Korean Company
Why the Project Started
The company already had SAP and a homegrown ERP. More than ten years had passed since it was built, so they were redefining work and task processes for next-generation development. The reason this company chose n8n was that it covered both security and AI agents. Few tools can be installed in a closed network and still connect AI agents.
A Top-Down AI Project
- Run training and the PoC as one package
- Reproduce existing work in n8n on servers built on a closed network, AWS, and Postgres
- Goal: define each organization’s work and develop it end to end
It was a classic large-company AI project: decide from the top, build from the bottom.
Three Company Problems
- Even the same work is structured subtly differently by person and by affiliate. Take HR management: “I did it this way” and “No, I do it this way” repeat in every meeting.
- There are no metrics for PoC success. Without time and cost measurement for existing work, there’s no baseline to compare against.
- The company needs isseobility (a Korean slang term for the look of sophistication or prestige). For the money spent, the company needs clear metrics or deliverables that show results.
Problem 1. Inconsistent Workflows
When the same work is handled differently, you need a common abstraction that can structure it. To define one workflow, you need to settle three things:
| Question | Meaning |
|---|---|
| What | Which source materials and data we start with |
| When | At what point in time |
| How | How it gets organized |
For example, it’s agreeing on one line: “When a contract arrives by email, get the internal legal team’s review back, and finally submit a draft.” That agreement was the longest part of the process. It was an n8n project, but most of the time went into work-definition meetings, not the canvas. The upside: the results remained as an n8n canvas, so work that had been fragmented was consolidated into one diagram.
Problem 2. No Success Metrics
What is the target metric for a PoC’s success? Ask that question and the answer is usually something like “Automation worked, yay?” Does a workflow running once count as success? The next question always comes: “So how much better is it?”
Fix 2. Measure It If It Isn’t Measured (a.k.a. A/B Test)
There’s probably no large company where every task is fully recorded and digitized. So if nothing is measured, you measure it yourself.
- Quantitative: Measure and compare actual work hours before and after development
- Qualitative: Interview the people who do the work about their experience after adopting n8n
Nothing fancy: no big dashboard, just a stopwatch and interview notes. You need these two things for numbers to appear in the PoC report.
Problem 3. The Company Needs Isseobility
At the venue, I played a short video at this point: a back-end developer presenting, with nothing visible on screen, so the audience reaction was flat. It got the biggest laugh of the talk.
Companies talk in deliverables. If you’ve spent money and time, there should be results. But n8n’s execution flow alone isn’t enough to show. Try demonstrating nodes lighting up green in front of executives. It’s like comparing front end to back end. However well the back end is built, without a screen you get asked, “What did you actually do?”
Fix 3. Build the Front End with Claude
This is where I brought in Claude Code.
- Use Claude Code to build a website (HTML file) reflecting the task, with mock data.
- Show the webpage to people inside the company and get their review of whether the layout fits.
- Organize the review results and pass them back to Claude Code.
- Connect n8n, webhooks, and HTML (CSS).
Once the screen existed, something surprising happened. Requirements that never came out in meetings poured out as soon as people saw the screen. “This button should be over there,” “our team doesn’t use this field.” It’s exactly what requirements-elicitation research describes: a prototype reveals requirements that stakeholders can’t express on their own.
Lessons (Large Company)
- For a large company that needs to visualize workflows, n8n is an attractive option (Explainability).
- Even if convenience is lower, it’s an excellent sketchboard for turning users’ work into a system.
- But for isseobility and user experience (UX), front-end web development is unavoidable.
The point of this PoC wasn’t automation itself. The company was moving to a next-generation system, and n8n was the intermediate step. Practitioners looked at one n8n workflow screen together, defined their own work, and carried those definitions into system design. Work that was different from person to person, once drawn as nodes, converged into one agreed picture, and that picture became the design input for the next-generation system.
For IT managers, my message is this: n8n is the back end. Don’t try to report the project on the back end alone. Build one screen first. That screen draws out the requirements.
Case 3. One-Person Business
Getting Started
The third case is my own story. When I first saw Claude Code, I dismissed it. “Isn’t it just a coding tool? It’s a developer’s tool, so what use is it to me?”
Thinking About It, All Our Knowledge Work Happens on Computers
Then I realized: the meeting notes (docx), presentations (PPT), and research (web search) we write all happen on a computer. Every task can be turned into code. From then on, I started every task with Claude Code. Below are three automations I built that way.
Use Case 1. Retrospective System
Each work session is automatically logged to Notion Calendar, and the same content is saved to Obsidian. Costs (tokens) and key decisions are recorded too.
I’ve published this logging pipeline on GitHub. The design is in the Operations Telemetry doc, and the Stop hook script that writes to the calendar and work log when a session ends is in claude-worklog. You can download it as-is and plug it into your own calendar.
These logs are collected, and a retrospective arrives on Discord every week. On the left is the qualitative summary (key achievements, themes that took the most effort, what to watch next week). On the right are time totals by project.
The monthly review format, which looks at tokens, costs, and project distribution, is posted with an anonymized sample report at Claude Monthly Review.
Use Case 2. Tracking My Book’s Rankings
Every morning, I scrape the rankings of n8n Does It All from YES24 (a Korean online bookstore), Aladin (a Korean online bookstore), and Kyobo Book Centre (a major Korean bookstore chain), send them to Discord, and draw a trend graph. I built it with the hope of “please stay in the top 100.”
Use Case 3. Sharing My Work Schedule
The problem: when I work outside work hours, my wife is stretched thin by childcare. The fix: every Sunday, I summarize my work Google Calendar and share it. Each week, I get a summary of the days that need childcare coverage and the important events for the next month.
Benefits of Switching to Claude Code
- You can automate every task.
- You can use open-source tools from all over the world.
- I feel like a skilled engineer.
The third one was the trap.
One Thing That Felt Off
Is Claude a cure-all? At first it seemed to work well. But as I tested and operated it, the operating structure kept breaking and bugs kept appearing. And there I was, repeating “do this, fix that” over and over.
Cognitive Debt, Technical Debt, Intent Debt
These are the things I was losing by using AI. The diagram above is the Triple Debt Model, which describes the health of software in the AI era: intent debt, technical debt, and cognitive debt amplify each other. Here’s my case, one by one.
Technical Debt
- Since I started using Claude, my growth in technical knowledge stalled.
- Good prompts and designs come from engineering knowledge, and that knowledge felt like it had stopped.
- When I stopped digging into root causes and solving problems, the operating systems kept breaking.
Intent Debt
- I wanted it to figure out what I wanted and handle it neatly, with good taste.
- But work involves relationships with people, the intent I read into things, and contextual information, and the AI couldn’t turn those into action.
Cognitive Debt
I didn’t accurately understand what I’d built through “do this” and “build this.” I trusted that it had probably done a good job, but when I opened it, it wasn’t actually built properly.
Book ranking tracking is an example. I told Claude “build this in n8n,” and at first it produced a two-node workflow: one schedule trigger and one code node. All the collecting, parsing, and saving lived inside that code node. About two months later, one bookstore changed its page and the whole thing died, and I couldn’t tell where it died. When I asked for a rebuild, a version with many more nodes appeared, like the one on the right. What both versions have in common: I wasn’t understanding the structure.
Lessons (Solo Business)
- I felt more productive using Claude Code.
- But when operations broke, it wasn’t as robust as an n8n workflow.
- I had to leave observability of where things broke to the AI.
- Putting it together, I realized I was losing out on time and cost.
This case will sound closest to those who have to bring AI into their work alone, without company support. Starting with “do this” is fine. But check each time whether you can explain what was built. An automation you can’t explain isn’t really yours when it breaks.
Lessons by Case
| Case | Lesson |
|---|---|
| Hospital | A good tool for non-developers. But proper design and operation are a separate stage |
| Large company | Consolidating scattered workflows into one n8n flow has value in itself |
| Solo business | Even with agentic coding tools, good operations are hard without overcoming technical, intent, and cognitive debt |
My Conclusions from the Three Cases
Which Workflows Should Go into n8n?
Apply it to workflows that need observability.
The screen above is the execution list of my expense-ingestion workflow. It runs every 15 minutes, and the left side stacks how long each run took and whether it succeeded. Click one, and you see what passed through which node. A script built with Claude Code has none of this. When it breaks, you dig through logs or ask the AI again.
If it involves integrations and schedules, if history must be kept, and if someone may later need to ask “why did this happen?”, keep it in n8n. If you need a screen, go outside n8n, into code. Work with no criteria and no owner needs to be settled by the organization before any automation.
How Should You Build in n8n?
Design it following n8n’s single responsibility principle (SRP).
The left is the bad example: two nodes, with everything crammed into one code node. The right is the good example: environment setup, collection, mapping, LLM judgment, validation, and loading are each split into their own node. Having many nodes isn’t what makes it good. Because each node does only one job, when something breaks you can immediately see which node it is, and you fix only that node. When you have Claude build an n8n workflow, unless you state this principle explicitly, you’ll get the left-side result.
What Should You Study Next?
In the agentic era, I read books that deal with abstracted knowledge more than use cases. Use cases like “automate email with n8n” are generated by AI for you. What you need instead is the eye to judge whether what the AI built has the right structure, and that comes from principles like software architecture. The book I recently re-read is Fundamentals of Software Architecture.
Takeaways by Reader
| Reader | What to do first |
|---|---|
| HR manager preparing for AX | Before picking tools, draw the “operations owner” into the org chart. Turning rules that exist only as tables, like approval lines, into written definitions is the first task in AI adoption |
| IT manager | n8n is the back end. Before the PoC report, first build one screen (HTML mockup) and collect requirements through that screen. Measure success directly with before-and-after work-hour measurements and interviews |
| Office worker who has to use AI without company support | Start with “do this,” but check whether you can explain what was built. Automations that must keep a record go in n8n, with one job per node |
Q&A
After the talk, I took questions on LinkedIn: in/jayjunglim. Questions about this post can also be sent there.
Frequently asked questions
- Why did the hospital receipt workflow switch from a chat interface to a form?
- The Chat node required precise input requests, handled multiple files poorly, and needed login and chat history management. The team switched to the On form submission trigger with fixed fields.
- Why did the n8n receipt project drop its multi-agent design for one OCR step?
- Chaining three agents at 95% each lowers the overall success rate. In 100 test runs, a document-specific parsing API got every receipt right in about 4 seconds, so the team used one OCR step.
Want the full system? The Claude Code & Codex Skills guidebook collects the skills and subagents behind this blog, from $19.
BuildnWrite helps teams build AI agents that keep running. About BuildnWrite ›