What n8n Taught Me About Product Prototyping

Product ideas often can be expensive to validate. Before something becomes a real product, teams/individuals frequently need to answer a simple question: does this idea actually solve a problem worth tackling? Over the last few months, I discovered that low-code automation tools can be surprisingly effective for exploring that question.

Ghazaleh Motia

Product Owner|MB.ioneer since September 2022

Fun fact:

Ghazaleh speaks 5 languages. Portuguese is on the fast track to be the 6th but it’s still not that advanced, she says.

Early this year, I opened n8n for the first time.

I had no developer background, no technical training, and no real idea what I was doing. I simply wanted to get closer to AI (Artificial Intelligence), not by reading about it, but by building something with it.

One of those experiments eventually evolved into a real web application.

Looking back, the biggest thing wasn’t n8n itself, it was how to think for software developement. And, more importantly, I discovered a surprisingly effective way to prototype products before writing a single line of production code.

Recently I’ve joined AI foundation stream to contribute to building automations with n8n.

I know as a nontechnical person it can be intimidating, challenging and overwhelming to keep hitting a closed door and not understanding why things don’t work! I wanted to share that it’s okay to do try and error for 10 times and still feel frustrated. But believe me the learning is worth it.

Automation and AI are different and understanding that changes everything

One of the biggest misconceptions I see is people using “AI” and “automation” interchangeably.

They’re not the same thing.

Automation answers questions like:

• When should something happen?
• What data should move where?
• What happens next?

AI answers different questions:

• What does this information mean?
• What should be written, summarised, categorised, or generated?

Once I understood this distinction, designing workflows became dramatically easier. Every time something broke, I knew whether I had a logic problem or an AI problem.

That single mental model probably taught me more than any tutorial I watched.

The first experiments

Like most people, I started small. I built a workflow that takes a base CV and a job description and produces a tailored resume. The automation gathers the documents, triggers the workflow, and delivers the final version through Telegram. The AI decides what skills and experiences deserve more emphasis. It still benefits from a human edit, but it completes most of the initial work in seconds.

Then came a finance tracker, weekly recipe reminders, and an AI writing assistant that turns rough thoughts into complete Substack drafts in my own writing style.

None of these projects was particularly sophisticated. But every one of them taught me another piece of the puzzle.

Each workflow forced me to think about inputs, outputs, states, exceptions, and user interactions, not unlike designing a product.

Going close to home

Then there was Zanbil, the Persian word for basket, the personal project that changed everything. Every week, my household had the same conversations.

• “Do we still have milk?”
• “Didn’t someone already buy rice?”
• “Who bought the eggs?”

It wasn’t a difficult problem, just repetitive enough to become annoying. So I decided to automate it.

The first workflow wakes up every Friday afternoon. It looks at our shopping history, checks purchase frequency, and predicts what we’re likely to need that week. There’s no AI involved here. It’s purely automation: scheduled triggers, data, and business logic.

A second workflow transforms that information into a Telegram checklist the household can interact with.

The third workflow manages everything after that: checking off items, adding new groceries, confirming purchases, and keeping everyone’s list synchronized. For a while, it worked surprisingly well.

Then I hit a wall! I found myself spending hours trying to make Telegram behave like an application it was never designed to be. Every workaround solved one problem while creating two more. n8n’s data table limitations added even more complexity behind the scenes.

Eventually, I stopped asking myself: “How do I make this work?” Instead, I asked: “Should this even live here?”

That question changed everything. The UX wasn’t wrong. The tool was simply no longer the right place for the product.

Looking back, that was the moment I understood the real value of low-code prototyping. The workflow wasn’t the final solution. It was a fast way to test assumptions, discover friction points, and understand what users needed before investing in a fully developed application.

So I kept everything that mattered (the purchase frequency logic, the household data model, the checklist behaviour, and the state management) and rebuilt it as a proper web application.

n8n was never the destination, but the place where I discovered what the product actually wanted to become.

Why this matters for product development

Before this, every product idea felt like it needed engineering time before it could become tangible.

Now, I can prototype workflows, validate assumptions, test interactions, and discover edge cases long before asking anyone to build production software.

Will these workflows replace engineers? Of course not.

Production systems demand architecture, security, scalability, testing, and countless technical decisions that no visual automation tool replaces.

But that’s not the point. The point is learning. The point is reducing uncertainty. The point is finding out whether your idea deserves to exist before investing weeks or months, building it.

As someone working in product and UX, that’s incredibly empowering.

Three things I’d tell anyone getting started

1. Think in logic, not code

You don’t need to understand programming syntax to build useful workflows. Instead, ask yourself three questions:

• What starts this process?
• What happens to the information?
• Where does the result go?

If you can answer those, you’re already thinking the way workflow automation does.

2. Build something you actually need

Every project I built solved a problem I personally experienced.

That mattered. When things broke, and they often did, I already had a reason to keep iterating. Curiosity gets you started. Personal frustration keeps you going.

3. Don’t mistake the tool for the product

Some workflows stay workflows. Some become products. Some teach you why they shouldn’t exist at all. Success isn’t measured by whether everything stays inside n8n. Sometimes success is realizing you’ve outgrown it.

The Real Lesson

When I first opened n8n, I thought I was learning another AI tool. I wasn’t.

I was learning how software thinks. Automation taught me to think in triggers, state, dependencies, and logic. AI taught me where interpretation belongs and where it doesn’t.

Together, they’ve changed the way I approach product design.

What started as curiosity about AI, ended up changing how I approach product discovery. Not because I learned how to code, but because I learned how to experiment, iterate, and learn from real interactions.

Building MVP is a core part of software development so it’s not a matter of sometimes. It’s more of how n8n and AI can speed up the process, make it cheaper to test and faster to fail.

If you have a repetitive problem and enough curiosity to drag a few boxes onto a canvas, you might surprise yourself. You don’t need to know how to code to start thinking like a builder.