How to Automate Work with Low-code π
Use cases, patterns, and a comparison of the most popular tools.
One of the most frequent pieces of advice I give to startups is to buy more, rather than build.
I believe that, as engineers, we have a bias towards building, because we like to create stuff and to be in control of things. This sometimes makes us forget that, for any problem we may have, writing bespoke code is the most expensive way to solve it.
Code, in fact, lives a long and laborious life. It gets developed, maintained, evolved, and, even under the best intentions it may eventually turn into debt, dragging down productivity for new stuff.
All of this, to be handled by the most expensive part of your workforce: engineers.
So, my take is that you should only build what gives you a significant competitive advantage and deserves to become a core IP of your company.
Conversely, you should buy anything that isnβt core to your product. Which is, probably, 90% of what you do.
Now, this is the point where people roll their eyes and think βoh boy here is another hippie who thinks you can use no-code for everythingβ. Because thatβs how many think of the buy vs build idea: you either use no-code or write 10K lines of JS.
But options are more nuanced than this.
Buy vs build is a continuum that includes no-code vs full-code on the extremes, but plenty of in-betweens, too. And, I suspect, thatβs where the blind spot is for many engineers.
There is a lot you can do by integrating stuff and patching things together. Most products these days play nicely with each other β they have good APIs, webhooks, and there exist plenty of glue tools and frameworks you can use to simplify the stitching.
These options shine especially for when you need to create automation.
Automation is a broad term which, in software, is usually about workflows to increase your teamβs productivity and remove manual, boring work.
So, this week I sat down with the guys at n8n, one of the largest players in this space β and one of the very few open source ones β to get some help in drawing a picture of this landscape.
Here is what we will cover:
π― How to use automation β use cases, advice, and mental models to empower your team productivity through software.
π How to create automation β patterns, tools, and modes of integration.
βοΈ Tools comparison β the definitive guide for choosing between the most popular options, with a special focus on low-code ones.
Letβs dive in π
Disclaimer: I partnered with n8n for this piece and I thank them for their support.
However, the goal of this is to provide an unbiased overview of the whole automation landscape, rather than promoting specific tools. I have tried personally and extensively all the tools and use cases mentioned in the article, and I will provide my 100% honest take about them.
π― How to use automation
Before Refactoring, I worked 1.5 years at Translated.com, where we built internal tools and automations for improving the work of 100+ people on the team.
Internal tools are where you can find the most opportunities for low-code automation, for several reasons:
π€Ή Tools spread β in modern companies, work is usually spread across multiple tools. The better you make such tools work together, the more productivity you unlock.
β‘ Volatility β workflows change often, and so should internal tools. Low code solutions are easy to evolve, and for small changes you may not even need engineers.
π· Citizen developers β internal tools are special products for which your teammates happen to be both domain experts and final users. Making sure they contribute in the building phase is a great opportunity to 1) expand your capacity, and 2) build the right thing.
But how do you find automation opportunities?
Finding what to build
To spot inefficiencies, there are two angles that I found particularly useful:
π Reduce boring work β what work can be automated? This question is popular these days because of the AI surge, but there is plenty you can automate even without AI. In most companies you will find opportunities for data entry, triaging, repetitive emails, and more.
β Reduce waiting β what are people waiting for? In a 2017 survey by Pluralsight, engineers reported that the biggest offender to their productivity is waiting for other people to do stuff. This is true in most departments, even outside engineering. Look for situations when people wait for something to happen, and you will find fantastic automation ideas.
The problem is, you canβt just survey people about these things, because:
People donβt know what manual work can be simplified or eliminated.
People donβt always realize they are unnecessarily waiting for stuff.
And yes, that includes developers. That probably includes you! When you are deep in the trenches of daily work, you see the trees but you donβt see the forest anymore.
(Are there trees in the trenches? Probably not, but you get the idea).
So, how can you find these issues? In two ways π
π£ Talk with literally everyone β different people look at things from different angles. Leadership may have the high-level perspective but miss the reality of practical work. Senior and Junior people may face different challenges. When you look at some process, talk with all the stakeholders, collect all the opinions, and draw your own conclusions.
π» Shadow people β this is crucial to seeing first-hand what people really do, as opposed, sometimes, to what they say. Sit down with them and look at how they work. See what they spend the most time on. You will probably learn more this way than by interviewing them (but you should do both!).
𧩠Automation patterns
By doing this over and over, I have found a few recurring patterns for improving workflows. I list them here so you can go through them and ask yourself βis there anywhere I can apply this?β.
1) π² Notifications
You can vastly reduce waiting times by changing interaction patterns from pull to push. Make information reach people directly, instead of having them poll for it.
Look for situations where people check for things manually, or have to manually notify colleagues, and build automations around these. Send notifications to the tools people already use, like Slack or email.
Simple examples are notifications throughout the dev process, like whenever a ticket is opened, or a PR is submitted and is waiting for your review.
2) πͺ Enriching
Make your existing tools do more. Attach more information/actions to tools people already use to get quick wins that are easy to adopt.
Look for situations where you can reduce the toolsβ spread and make people do more with less.
Examples:
Display shifts on Google Calendar
Generate PR descriptions with AI
Automatically enrich leads
Adopt ChatOps tactics inside Slack/Teams.
3) ποΈ Data entry
Reduce manual input, extraction, and copy-pasting of data. Look for situations where people have to manually enter info that is repetitive or doesnβt require a lot of intelligence.
Here are a couple of ways to do so:
Pure automation β move information automatically between tools. E.g. create Notion pages for Linear tickets, or sync the various project mgmt tools (this is a classic).
Scraping β build simple scrapers to get info that people would otherwise take manually from websites.
4) π Triaging / Routing
Sometimes, processes can be simplified by adding an initial step that does some work and then routes tasks into specific directions.
Think of routing customer support tickets, or labeling inbound emails. But also less obvious ones, like automatically assigning the reviewer of a PR.
5) βοΈ Drafting
Many complex tasks canβt be completely automated, but can be vastly simplified by creating an initial draft automatically, to be later reviewed/improved by a human.
The cognitive effort of reviewing something is usually lower than creation from scratch, so you save both time and energy.
AI is obviously good at this, but even simple templates and checklists are a great example of drafting. Is there anything you do frequently for which you can create good templates? Can AI write a first draft of some docs/emails based on the info you feed it?
Now that we've covered some patterns, how can you build this stuff? Enter the various integration modes π
3οΈβ£ Three integration modes
For the sake of simplicity, letβs bucket the various automation options into three main categories:
1) 𧩠Direct
Popular tools can often work together directly. Whenever available, this is the most straightforward option. Here are some examples:
Notion β Github β display a preview of Github PRs, issues, and more, directly inside Notion.
Linear β Slack β display issues, comments, and project details, and make quick actions inside Slack .
Glide β Airtable β build apps and internal tools directly on top of Airtable or Google Sheets.
More and more of these options are available today. Airtable launched Automations, Webflow launched Logic, and so on.
There is a clear trend for simple workflows to become available inside the respective tools, as opposed to relying to external pipes. Still, for more complex scenarios you need something more powerful π
2) πͺ Low-code
There exist several products specialized in building workflows and connecting tools together. Zapier pioneered this space and is still probably the most famous one, but other great ones include n8n, Make, and Stackstorm.
While directly competing with each other, such tools also specialize in different use cases, based on features like branched workflows, custom connectors, or self-hosting.
3) π» Code-based
When low-code recipes are not enough, you can write code to build 100% custom workflows.
Most of the low-code products above allow for custom code execution, but if you want a solution that is 100% bespoke, you can switch to dedicated environments like Pipedream or Autocode, or to coding things completely in-house.
πͺ Low-code automation tools
Out of these three categories, the most interesting to me is the low-code one, for simple reasons:
Direct integration wins whenever available, but itβs mostly about simple stuff.
Code-based integration is clearly more powerful, but we all know what we can build with code, so no surprises here.
Conversely, I feel most people are genuinely in the dark about what you can build with low-code tools. Can you branch executions based on custom conditions? Can you throw in some code when needed? How much does this cost at scale?
Letβs wrap up this article by comparing three of the most popular products in this space β Zapier, Make, and n8n β to figure out 1) what you can do with them, and 2) what is the best for you.
Letβs analyze them based on four coordinates: Integrations, Logic, Cost, and Deployment.
1) π Integrations
Integrations are the heart of any automation tool. Zapier totally dominates in absolute numbers, with more than 5000.
Zapier: 5000+
Make: 1600+
n8n: 400+
There is more to it, though. Each connector on these tools features some triggers and actions.
Triggers β are conditions that you can use to start some execution. E.g. a new email is received.
Actions β are tasks you can perform on the relative tool. E.g. create a ticket on Linear.
Now, while Zapier has definitely the most connectors, I have found that Make and n8n generally provide more triggers and actions per individual connector. Make explicitly says that it features 2x more API endpoints per app than Zapier, which pretty much mirrors my experience.
This is natural as Zapier is mostly used for basic automations, while Make and n8n are optimized for more complex workflows (more on that below).
2) βͺοΈ Logic
All the three tools feature the basics: multi-step actions, conditional actions (branched paths), and custom code execution.
However, especially for advanced, branched workflows, Make and n8n feel like the best choice in terms of UX and capabilities. Zapier added paths about a year ago, but the UI is hard to navigate and it kind of feels like an afterthought.
Make and n8n, instead, both feature a flowchart-like interface that feels native to this kind of interaction. They also allow for sophisticated loops and you can build pretty much anything you can draw in a flowchart.
3) πΈ Cost
Cost is a tricky topic because pricing models are different and itβs hard to compare apples to apples.
Zapier charges per execution, where an execution can include any number of individual actions.
Make charges per individual actions (called tasks). So e.g. a single execution with 8 actions costs twice as much as an execution with 4 actions.
n8n charges per execution, like Zapier.
So, costs may change based on the number of executions you need, plus the number of steps/actions of each execution π
Zapier is the most expensive on simple executions, but it scales surprisingly well on complex ones. Make and n8n are comparable on simple stuff, but Make gets expensive pretty fast as complexity increases.
4) π Deployment
A big difference that may or may not be relevant to you is about hosting.
Make and Zapier are only available as hosted tools, with SaaS plans. n8n instead is fully open source and self-hostable, which is a solid option for larger orgs and those concerned with portability.
If you are in the market for self-hosted options there are other solutions, too, like Stackstorm, or Rundeck. These, though, do not have a managed version, and have a steeper learning curve.
π Bottom line
I have spent two weeks building workflows and automations with Zapier, Make, and n8n, and tried several others.
Here is my take:
Zapier β works best as the friendly, generic automation tool that anyone on the team can use for simple stuff. It has integrations with pretty much anything, and can be easily picked up by non-engineers. It is also surprisingly cost-effective for large executions, but it misses many features and the UX isnβt really viable for those.
Make β works best for complex, specific use cases, for which you donβt have a heavy workload.
n8n β is best suited for running complex automations at scale. Features are comparable to Make but it has the best pricing model for large workloads, plus it can be self-hosted, which is also useful as a budget play.
Thatβs it for today! See you next week! π
Sincerely,
Luca
This is great, Luca!
If there was ever a single article that can soften rigid corporate and enterprise bias against no/low-code tools, this is it. Excellent writing and a very accurate assessment of automation and workflow adhesives.