Automate with a tool or commission custom development
The question is not which is better. It is how much it would cost to redo it if in two years you need something else.
The question arrives framed as a duel: Make or custom development? n8n or writing code? Put that way it has no answer, because both options are good and the choice does not depend on which one is better.
It depends on something else, less obvious: how much it would cost you to rebuild it if in two years you need something different. Because you are going to need it.
What each one is
An automation platform — Make, Zapier, n8n, Power Automate — is a canvas where services that already exist get connected: when a form comes in, create a row, send an email, send a notice over WhatsApp. It is assembled by dragging blocks and configuring each one. The platform supplies the connections ready-made, runs the process, retries it if it fails and keeps a record of what happened.
Custom development is writing the program that does exactly what is needed, running wherever you decide. There are no blocks: there is code, and with it total control and total responsibility.
The underlying difference is not “easy versus hard”. It is where your business rules end up stored: the steps, the exceptions, who decides what. With a platform they sit inside a provider's account, and they can only be read and changed from there. With your own development they sit in files that are yours and that you can take elsewhere. Everything else follows from that difference.
Six criteria for deciding
1 · How standard the thing you want to connect is
If they are well-known services — Google Calendar, a popular customer system, a spreadsheet, email — the platform already ships the connection to them, ready and tested by thousands of users before you. There it wins by a wide margin: what would take a programmer days is assembled in hours.
If what has to be connected is an old in-house program, or a service the platform has no ready-made connection for, it has to be built by hand inside the platform. That is where the advantage ends: you end up programming anyway, but in a tool that was not designed for it. It is the worst of both worlds.
2 · Volume
Platforms charge for every time the process runs, or even for every step inside it. With little activity it comes out cheap. With a lot, the subscription for the same process can end up costing several times what a small server costs, because the bill grows with use and the server does not.
Do the arithmetic with next year's volume, not today's. It is the projection that decides, and it is the one almost nobody does.
3 · How tangled the logic is
A linear workflow with two or three conditions reads perfectly on a visual canvas. A workflow with fifteen branches, loops and special cases turns into a plate of spaghetti that only the person who drew it understands — and that nobody dares touch once that person leaves.
The warning sign is concrete: when boxes of hand-written code start appearing inside the canvas — to solve what the ordinary blocks cannot reach — you are already programming. Only in the worst place to do it: with no history of who changed what, with no way to test before publishing and with no one else able to review the change.
4 · Who is going to maintain it
This criterion decides more often than the other five together.
If there is someone inside the company with judgment and no programmer's background, a platform gives them real autonomy: they can adjust a text, add a step, see why something failed. With custom development, every change goes through a third party.
If there is nobody — if maintenance is going to be external anyway — that argument disappears, and with it a good part of the platform's advantage.
5 · What happens with the data
On a platform, the data in the process passes through the provider's infrastructure. For most processes that is perfectly acceptable. For sensitive personal data or information covered by confidentiality agreements, you have to look at where it is processed, how long it is kept and what the contract says. The criteria are in what data should not leave the company.
It is worth noting that some of these platforms can be installed on your own infrastructure — n8n is one of them — which leaves them halfway between the two: the convenience of a platform with the data at home. It is a possibility that gets forgotten in this discussion and one worth asking about before ruling out the tool route.
6 · What it costs to get out
It is the question almost nobody asks at the start, and the one that turns out most expensive when the moment comes to have to answer it.
A process built on one platform does not move to another: it gets built again, because each one defines workflows in its own way. If the provider raises the price, changes the terms or shuts down, the work has to be redone. Your own development moves to a different server with predictable effort. The exception is the tool that can be installed on your own infrastructure: there the change is of server, not of platform.
This does not decide anything on its own. It is simply one more cost worth having written down from the start, alongside the others, and one that almost never is.
The short table
| If… | The better fit |
|---|---|
| It connects well-known services, simple logic, low or medium volume | Platform |
| Nobody technical in the company, but someone with judgment who wants autonomy | Platform |
| You have to validate before knowing whether the process is any use | Platform, always |
| High, sustained volume | Custom-built, on cost |
| Logic with many branches and special cases | Custom-built, on maintainability |
| The process is the heart of the business | Custom-built, on control |
| Data that should not pass through a third party | Custom-built, or a platform on your own infrastructure |
The three signs of the breaking point
Almost nobody chooses badly at the start. What happens is that the choice is made well and never revisited. These three signs say the platform has become too small for you:
- The monthly bill already pays for a server, with money to spare. Simple arithmetic, and it usually happens without anyone looking at it.
- There are blocks of code inside the canvas. You are already programming, in the worst possible place to do it.
- Nobody dares touch the workflow. When a small change is frightening, the system has stopped being maintainable, and that is a problem even if everything works today.
The recommendation we give most often. Start on a platform and be prepared to leave it. Validate first that the automated process is any use — many are not, and finding that out cheaply is a victory — and rebuild it custom only when one of the three signs appears. Building custom from day one a process nobody has tested is the most expensive way to learn that the process was badly thought out.
The answer that usually wins: both
In practice the healthiest thing is not to choose one, but to divide the work according to what happens if something fails. What sits at the edges and changes often — internal notices, reports, moving data from one office tool to another — lives very well on a platform: if it goes down for an afternoon, nobody is ruined. What holds the business up and cannot fail is built custom.
That way you pay for control where control matters and for convenience where convenience is enough. And to decide which of the two groups each process falls into, the twelve questions of the buying script are what to use.
How we can help with this
This article gives you the six criteria and the table. The hard part is applying them to a specific case, because almost no process falls cleanly into a single column:
- Deciding for your case, with your six answers and not the example's: what gets connected, how much activity it has, how many exceptions, who is going to maintain it, what data it touches and what getting out would cost. What comes out is a recommendation with the reason written down, not a verdict.
- Building it on the platform if that is the answer, and leaving it documented so that someone on your team can touch it without fear. Autonomy is half the advantage of a platform, and it is lost if nobody explains how the thing is put together.
- Developing it custom if the case calls for it, with the credentials and the infrastructure accounts in your company's name, and ownership of the deliverable agreed in writing before starting.
- Taking it off the platform when the three signs appear, without switching off what already works while the change is made.
If you have a process in mind and do not know which of the two columns it falls into, the technical division goes over it with you in a thirty-minute meeting and tells you which one it would recommend and why. No cost, no obligation to hire us.
Frequently asked questions
Which is better, Make or custom development?
It depends on six things: how standard what is being connected is, the volume, how tangled the logic is, who is going to maintain it, what happens with the data and what getting out would cost. As a general rule it is better to start on a platform to validate that the process is any use, and to rebuild it custom when the bill already pays for a server, when code has to be written inside the canvas, or when nobody dares touch the workflow.
Is automating with a tool cheaper than programming?
At the start almost always yes, because the cost of getting going is much lower. At high, sustained volume it reverses: the subscription grows with use and your own development does not. The comparison has to be made with volume projected a year ahead, not with today's.
Can the two approaches be combined?
It is the most common thing and usually the healthiest. What sits at the edges and changes often lives on a platform; what holds the business up is built custom. That way you pay for control where it matters and convenience where it is enough.
What happens if the automation platform raises its price or shuts down?
A process built on one platform is not migrated: it is built again on another one. That cost should be accounted for from the start. An intermediate alternative is to use a tool that can be installed on your own infrastructure — n8n is one of them — which keeps the visual convenience without depending on the continuity of someone else's service.
Sources and notes
- The criteria come from Navhera's practice building and operating its own automations, both on a platform and custom-built. No prices are quoted for the platforms mentioned because they change frequently and vary by plan; the comparison has to be made with the rates in force on the day of the decision.
- The decision criteria come from building and operating our own automations with both approaches.
Written by the Navhera team and reviewed before publishing. If you spot an error, write to us and we will correct it with a note.