How I'd Learn n8n if I had to Start Over in 2026

When I first started learning NAND, I brute forced my way through the learning process. And don't get me wrong, in a year I have learned a lot and become pretty proficient in Naden. But if I could start over in 2026, I'd do it completely differently because back then I thought the goal was to just build AI agents as quick as possible. But what I didn't realize is you can't build good agents until you understand workflows. And I think that's where everyone goes wrong. So in this video, I'll walk you through exactly how I'd learn Nen and AI automations in general if I had to start from scratch today step by step. So let's get into it. So, if I was starting from zero right now, the first thing that I would drill into my head is this. Do not start with AI. Start with workflows. Learn the automation fundamentals before you even think about building agents. Most beginners skip past this part because they want to build AI agents right away because they're cool and that's what we're seeing online. But the truth is, you cannot build good agents if you don't understand how workflows actually function. That's essentially trying to run before you can walk. So, here's how I would think about the three layers. You've got workflows. Those are rule-based, they're predictable, and they're boring, but in the best way possible. You know what the inputs look like, so you know what the outputs will be, and you can map those variables, set your own conditions, and it runs the same way every time. This is classic business process automation, and it has already been around for decades. But it's still one of the strongest ways to actually produce ROI. Mackenzie found that standard workflow automation alone can deliver anywhere from 30% to 200% ROI in just year 1 with labor cost savings of 25% to 40%. And most small businesses still do not have these basic automations in place. So, I firmly believe that you could literally position yourself today as just an automation agency or an efficiency agency and build a really solid business without ever touching AI and drive massive results for your clients. But AI automations are then the next step up because you still have those predictable workflows, but now you can sprinkle in some intelligence and some decision-making. Maybe you just need to use AI at the end of the workflow to personalize the email. Maybe you need it at the beginning to score support tickets as high or low priority. These are small controlled decisions inside a larger rule-based workflow. Mackenzie also estimates that about 50% of work activities and processes can be automated without using AI at all. So these AI assisted workflows do fit most use cases that a business will have. Then finally we have our AI agents which are the top layer. These systems can make decisions, reference memory, use tools and adjust based on context. They're super powerful, but they're also much harder to control and they have a higher likelihood of breaking. This is where people tend to get lost because they jump straight into these agentic workflows before they even learn variables and JSON data structures and how a basic workflow behaves. So this would cause you to get confused, things would break and then you'd want to quit. So workflows are deterministic and they're much more set it and forget it than AI agents are because AI agents are nondeterministic. As you have more and more AI, there's more possibility for errors which means you need constant maintenance and upkeep and evaluations to make sure that the systems are actually providing value rather than just becoming a headache. And once you understand that foundation, you'll want to learn the core building blocks that make every workflow actually work. Everything in NDN comes down to data coming in and then going out. And once you understand how the data is shaped and how it moves, the entire platform becomes way less intimidating. There's one thing real quick though I want to tell you guys about, and it's called the transition curve. In life, whenever you're trying something new or you're trying to learn something, you go through these phases. And it's good to be aware of them beforehand so that your expectations are aligned and you have the highest chance of success. Because I'm not going to lie to you, when you start the first time and you go to look at JSON or setting up an HTTP request or trying to prompt your agent, you're probably going to feel overwhelmed. I know I did. So, the transition curve is basically the idea that you start in phase one and you're on the up as an uninformed optimist because you see the opportunity, you see people building cool agents or making money with agents or whatever it is and you're excited about that opportunity. But then you kind of come over this hump and you become an informed pessimist in stage two. And this is on the way down because now you understand the complexities that go into all of this and you feel overwhelmed. As you move into stage three, you hit the crisis of meaning. And this is where you have a decision to make. You can either go to stage four and crash and burn, or you can use that momentum and go back up into stage five, which is an informed optimist. And that's where you want to be. This isn't just a one-time thing. In the past 12 months, I probably become an informed pessimist about 17 times. But now that you understand this whole cycle, it's much easier to push through the crisis of meaning and continue on your way up. So, I just needed to talk about that real quick before we hop into the next pieces because everyone feels overwhelmed when they're getting started. Anyways, the first thing to learn is JSON and data types. This is the language of almost everything that you'll touch in automation. And at first glance, JSON might look like code, but when you actually look closer, it's just pairs of keys and values. So, think about online shopping. You click on a product and you can see color equals blue, size equals medium, price equals $99.99. JSON is the exact same thing. It's just written in a specific structured format. And once you understand how you can read it and navigate it, you stop guessing and you start knowing exactly what data you have to work with. Next is APIs and HTTP requests, which is probably the most important skill that you'll ever have to learn in automation. This is how data moves between different tools. So if you don't understand APIs, you'll pretty much always be limited to whatever integrations that Naden gives you out of the box. The good news is Naden has thousands of native integrations with things like Gmail, Perplexity, Slack, HubSpot, and so many more. But once you realize that those nodes, those native integrations are actually just pre-built HTTP request just with a cleaner UI because Eniden packaged it up all nice for us. But the point I was making there is once you realize that, everything starts to click because you start to understand how you can connect to platforms that Eniden does not yet support. You can open up the API documentation. You can read about the endpoints. You can make the request and you can access whatever you need. And here's a quick pro tip. If you give something like chatbt or claude API documentation for any tool that you need, it can help you set up any request that you have to make. So it's really just about getting over that initial intimidation when you see the words header authentication. Then we have web hooks which basically just flip the flow around. So instead of end reaching out to another tool, the other tool reaches out to end and that's what triggers our web hook. This lets any of our workflows be triggered based on real-time events like receiving an email, getting a new Slack message, or someone filling out a form on your website. And finally, you need to understand logic and error handling. Learn what an if node does, learn how loops behave, learn how to route data in different directions, and understand what the workflow does when it errors and how you can change that. This is what helps you build workflows that are stable, predictable, easy to improve, and safe. It also teaches you how to think about data as it moves step by step through a workflow. But knowing how to move data isn't enough. You need to also understand how AI itself thinks. And that's where LLMs come in. An LLM or a large language model does not know your business. It does not know your clients. It does not know your internal processes. At its core, all it's doing is predicting the next word that would make sense. This is why you should never just blindly trust whatever an AI or an LLM tells you. So, in order to actually get useful outputs, you have to learn context engineering. This is one of the most important skills in modern automation. You've probably heard of prompt engineering before. Everyone's talking about it. And that kind of fits into this bucket of context engineering because prompt engineering is telling the model what to do, but context engineering as a whole is giving the model the information it needs so it knows how to think. These systems are only really as smart as the data and the subject matter expertise and real context that you feed them. So here's a simple analogy that I like to use. A system prompt for an AI is like studying the night before an exam. It helps the model understand the rules, the tone, and the structure and maybe some base knowledge. But good context is like having a cheat sheet during the exam. It gives you the exact details at the exact moment that you need them. So if you had to choose between studying and having a cheat sheet, most of us would choose the cheat sheet. But obviously the best results will come from doing both of those things. Well, this is how you should think about LLM's inside Nitn. The model's not magic. It's not a mind reader. It's only as good as the context that you give it. And once you understand that, you stop expecting the model to guess things and you start giving it information that it needs in order to perform well. And once you've got that mindset, the next step is to focus on building automations that actually matter. So that means ones that bring real results or save serious time. So think about it like this. Build systems that run while you sleep, not systems that sit there waiting for you to click a button or for you to talk to them. Because the whole point of automation is about leverage. You want workflows that save time without you being involved. So there are four pillars that I like to think about that help you judge whether something is worth automating. Repetitive, timeconuming, errorprone, and scalable. So if a process does not check at least two of those boxes, it's probably not something that's worth automating yet. And obviously the best automations hit all four. So a good example of this is when I released the ultimate personal assistant video on my YouTube channel. I had thousands of people reaching out wanting me to build it for them or customize it for them in some way. And while I completely get it because it would be great to have your own personal AI assistant that you can talk to, but that type of system only takes action when you tell it to do something. It's not constantly running in the background, at least the way that I configured it. So, it's really not creating a ton of leverage. Now, if you compare that to a workflow that's actually triggered by real events, like a new lead submitting a form or a payment coming in or a new email hitting your inbox, these systems wake up on their own. They take action automatically. They can run all day and all night long. And that is where you get to scale. And that's the type of work you want to focus on at the start. And this is something that I'm just like super passionate about. But if you think about it, let's say you design a system that saves the business time and grows the business. And because of all that time you're saving and all of the new growth the business is going through, that system that you built is going to get used more. So it basically just creates like this endless flywheel of value and exponentially scaling return on investment. And to consistently find and build those high ROI workflows, you have to start thinking like a process engineer. So what I mean by that is before you even open up and end, I would sit down, I would map out the process on paper. Most people just jump straight into the canvas and start dragging around nodes hoping that it will eventually come together. And that's how you end up with messy, fragile workflows that aren't modular, that aren't scalable, and that need tons and tons of refinement after you kind of push it into production. This also makes them harder to explain when you need to hand it over to a different engineer or when you need to explain how it's working to the team. So instead, just start by thinking like a process engineer. Break the business process into clear, detailed steps. Who does what? When does it happen? What triggers this? Where's the data coming from? What do we do with the data? What is the final outcome we care about? I think you guys get the picture. And from there, I like to wireframe it before I actually build it and ed it in. And this is exactly what I teach in my course, 10 hours to 10 seconds. If you want to dive deeper into this, then you can join my plus group. The link for that's down in the description. But here's the key idea. If you can't explain a process clearly on paper and get alignment with your client or your team, then there's no way that you can go automate that process clearly. It's essentially like you're dumping out a bag of Legos and then just tossing away the instructions. And you're trying to build the car from memory from the picture that you saw on the box of the Legos. You could eventually get something that kind of works, kind of looks like it, but it's going to take a lot longer and probably not be right. So, slow down at the start, map the process, get the steps right, get agreement from everyone involved, and then go into edit end and build it. That small bit of planning up front will save you a huge amount of time and headaches later. I always think of the a blinking quote. If I had 6 hours to chop down a tree, I would spend the first four sharpening the axe. So, once you've got all that figured out, now it's time to test and refine it in practice. If I could teach every beginner one mindset, it would be this. Your first version will break. And that's completely normal. You don't know what you don't know. The goal in the beginning is to fail fast, learn from it, and make the system better each time. And I don't mean just your first workflow ever. I mean your first workflow of every process you try to automate. Every time that I go and build a new system for a YouTube video or for me or for a client or whatever it is, I always get tons of failures and it breaks right away. But all of that is data that you can use to make it better. It's the same reason why Facebook ad experts or YouTube experts or whatever type of expert you have, even though they know what they're doing, they still split test everything and they still use all that data and findings to help continuously iterate in the future. So that's why we build PC's, proof of concepts, and MVPs, minimum viable products. They simply exist so that you can get something working, even if it's not perfect. Then you can monitor it and see where it breaks and fix those weak spots. In fact, you should honestly try to break your own workflows on purpose as much as you can. Push them to their limits, feed the edge cases, and just see what happens. Because the more weaknesses that you find early on, the stronger the final system will be. And a major part of this is actually tracking and logging. So every workflow that you build should have some sort of audit log on every execution. These will be stored in nadn, but it might not be permanent based on your setup. So, if you can have every execution feed into a Google sheet or an air table, that's really going to help you because you can find patterns and those failures, you can spot errors, and you can build guard rails that protect against those patterns so that they don't happen again. And your job isn't to build something once and then just walk away. Your job is to build something stable that stays working over time. And remember, of course, the more AI that you have in a workflow, the more that you need to monitor it. New chat models come out, APIs update, and then releases new nodes, new versions. AI does not behave the same way forever. So stay close to your systems, run regular checks, and make small improvements as things evolve. That is how you build automations that truly last. And while you're learning and building, avoid falling into one of the biggest traps that slows everyone down. They get stuck in tutorial hell. They spend all day watching videos, taking notes, and consuming content, but they never actually build anything. You cannot learn automation by just watching someone else click buttons. You have to go and get your hands dirty in NN or whatever automation platform that you want to use. So follow the tutorial, but then rebuild it yourself. Break things, debug them, try different variations. This is where the real learning happens. After a while, you'll notice something interesting. About 90% of all workflows will rely on the same 15 or so core nodes, and most errors fall into the same handful of categories. Once you master those, you can build almost anything with confidence. I even made a full video on those exact core nodes that I use after building hundreds of workflows. And I will link it right up here so that you can check that out. And once you know those nodes well and you start to build consistently, things begin to click. Automation becomes pattern recognition. When you hit an error, just try to understand how to fix it yourself before you go into a community forum. And then when you fix it, make sure you understand why what you did got rid of the error. That way when it pops up again, because it will, trust me, you know exactly where to look and how to make the workflow green again. And each time those patterns come up, you just get faster. So avoid tutorial hell and get your reps in. The more you build, the better you get. And when you finally hit that point of building with real confidence, the next logical step is turning what you've learned into something that you can actually sell. So if your goal is to build a business with automation, then you need to learn how to build systems that people will actually pay for. And the key to that is learning to speak in terms of ROI or return on investment, not in terms of tech. Clients don't care about all the tech jargon, the JSON, the nodes, or how clever your workflow is. They really care about three things: time saved, money saved, and better quality work. And sometimes I also say focus, but that kind of gets looped into all the others. So, keep things simple. Start with MVPs that actually solve a clear problem. Before you ever talk about AI agents or voice agents, make sure you can build something predictable that delivers measurable value. You understand the value because you have been building in the space for a while, but your clients are not in this world every day. It's your job to explain the value to them in a way that makes sense to them. And this starts before you build a single node. You should be able to clearly communicate the business impact of any system. What time it saves, what labor cost it removes, what errors it reduces, what scale this unlocks. And when you can actually speak in those terms, people will understand why the automation matters. And then, super important, once the system is live, you have to collect data. You have to track how often it runs, how much time it saves, and what outcome it produces. Because after a few months, you can then show them real numbers. And that's how you build trust. That's how you earn long-term relationships. You also need to use all of that data for your case studies. So, if you're not tracking it, you're missing out on tons of new business. And just wanted to stress this one more time. Your job is not only to build systems that work. Your job is to also communicate the value clearly and prove the value over time. And that's how you level up from being just a builder or a developer to being a long-term business partner. And if you follow that road map, you'll skip years of trial and error and go from building simple workflows to launching full-on AI systems that people will happily pay for. But anyways, that's going to do it for this one. If you enjoyed, you learned something new, please give it a like. Definitely helps me out a ton. And as always, I appreciate you guys making it to the end of the video. I'll see you on the next one.