How do you choose between Make, n8n, and custom code?

How many times have you watched your coding agent turn a paragraph of description into a working interface? It creates real pages with real data and functional buttons that lead somewhere, when in that same amount of time all you would have done is map the fields in a single module of n8n or Make. You close the tab, look back at the half-finished scenario on your canvas, and get the sinking feeling that you spent six months learning the wrong tool.

That feeling is reasonable. The cost of producing code has genuinely dropped, and anyone who tells you otherwise has not been paying attention. But here is a little secret: producing code was never the expensive part of delivering a system to a client.

How do you choose between Make, n8n, and custom code?

In our experience, the decision is about the whole operating system you are handing over, not about who or what typed the code. It is about who maintains it, who can open it and check why the run failed last Tuesday, and what happens when a Google token expires while you are on holiday.

Those questions have the same answers whether a person wrote the code or an agent did.

You have three paths, and all three of them are legitimate:

1. A visual workflow in Make or n8n, where triggers, actions, and data mapping live on a canvas.
2. AI-assisted custom software, built in an AI-assisted IDE like Cursor or with a coding agent like Claude Code or Codex.
3. A hybrid system, where your workflow platform handles the integrations and your custom code handles the interface, or that one piece of logic the platform cannot express well.

We have seen that most consultants treat the third option as a compromise. In practice it is often the easiest and most straightforward option.

How does each approach work?

Take one example and run it through all three. Say you run a consulting business. A prospect submits your contact form with name, email, phone, and message. The details land in Airtable, and a follow-up email goes out with a calendar link.

Make and n8n. The trigger is the form submission. The client's data moves step to step as a bundle or an item, and you map all four fields into the Airtable step, then into the email module that carries your booking link. Credentials are set up once per service and reused by every step that touches it. There are branches that split the logic, error handlers that catch failures, and every run lands in an execution log you can open and read.

Custom code. You build the form page from scratch, then write the request that creates the record:

await fetch(
  `https://api.airtable.com/v0/YOUR_BASE_ID/YOUR_TABLE_NAME`,
  {
    method: "POST",
    headers: {
      Authorization: `Bearer YOUR_ACCESS_TOKEN`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      fields: {
        "Name": formData.name,
        "Email": formData.email,
        "Phone Number": formData.phone,
        "Message": formData.message
      }
    })
  }
);

In addition to this, you write the email-sending script, store the token, deploy the page, and arrange your own logs.

Hybrid. The contact page is custom, because it is public and has to match your brand. It writes to Airtable, and a Make or n8n workflow watches for the new record and sends the follow-up.

What should actually decide the choice?

Both Make and n8n can call any API that exists, through Make's HTTP module or n8n's HTTP Request node, so "there is no integration for it" is one input to the decision rather than the decision itself.

Read the handoff row twice. Is this project your own, or something you are going to hand to another person? Is that person technically savvy? The handoff point decides most client projects, and it has nothing to do with what the software can technically do. If the person who will own this system after you leave is an operations manager, a canvas they can open and follow is worth more than elegant code they cannot read. If the client has an engineer, that changes the situation completely.

Interface is the other row that settles arguments quickly. If the client needs something their own customers will use, a workflow canvas is not a candidate, and no amount of cleverness on the canvas will make it one.

Where does each approach break?

A canvas that made sense at nine modules becomes something nobody wants to touch at forty, branches included. Testing and versioning only get more tedious as it grows.

And do not forget the pricing. Execution pricing is predictable only when you actually understand your operation counts and volume, and on Make one bundle per module counts as one operation against your plan.

Custom code has its own downsides. Environment setup, DNS, the error message that has nothing to do with your logic. Once you are past laying the foundation, you still have authentication, deployment, monitoring, and tests, none of which an agent removes from your plate, and the finished system depends on someone who can maintain it.

Hybrids do not make it any easier. When something fails, your first question is which side failed: the workflow, or your custom code? If you have not decided who owns each side and where the logs live, you will spend the entire outage finding that out.

What does a hybrid build look like?

Two shapes cover most of them: a custom front end over a platform data layer, and a custom call inside a visible workflow.

Custom front end over a platform data layer. Say you are using Airtable as your database. Airtable's own interfaces are fine internally, but when a page is public-facing or has to match a brand, you build a webpage that reads and writes through Airtable's REST API. Airtable stays the data layer. The page provides the experience Airtable interfaces cannot.

Never put the access token in client-side JavaScript. Anyone can view the page source. Route the calls through a serverless function that holds the token server-side.

Custom call inside a visible workflow. In n8n, the workflow stays on the canvas where anyone with access can inspect it, and a single HTTP Request node reaches the service that has no native node. Paste the cURL example from the API docs into Import cURL, save the key as a credential rather than hardcoding it, and the rest of the workflow carries on as normal.

Why does the tool choice matter less than the operating model?

Go back to the table and read every row as a question about the system rather than a point scored for a tool.

• Time to first working version: how soon does this have to be live?
• Authentication: who owns the credentials when a token expires?
• Debugging and observability: where does someone look when a run fails?
• Handoff: who owns this after you walk away?
• Interface: is this an internal tool, or will its users need a real interface?
• Deployment and data control: where does the client's data have to sit?
• Complex behavior and scale: what does this look like at ten times the volume?

The same questions apply when part of the workflow is a model rather than a rule. If your build has a step that reads a document or classifies a request, the design work is what AI automation actually is: deciding which step the model owns, which step stays deterministic, and who picks up the cases it cannot finish. The platform question does not answer that one.

Your clients and end users will never ask whether you built it in Make, n8n, or code. They do not think in those terms. What they are buying is logic that produces more revenue, better operational efficiency, or relief from a task that has become a headache for someone on the team.

What questions come up most often about this choice?