Make vs n8n vs custom code: how we choose the right automation tool for each project

We get asked this question on almost every project brief: "Should we use Make, n8n, or build it custom?"

The honest answer is that each has a real place — and picking the wrong one is one of the most expensive mistakes you can make early in a build. A system built in Make that outgrows it needs to be rebuilt. A system built custom when Make would have done the job costs three times as much to maintain.

Here's the framework we actually use.

When we use Make

Make (formerly Integromat) is our default for most service business automations. It's visual, it's fast to build with, and it handles the most common patterns well: webhooks in, API calls, conditions, and notifications out.

The cases where Make wins:

• Linear flows — intake form, qualification check, notification, CRM update. If the logic is mostly sequential with a few branches, Make is faster to build and easier to hand to a client who wants to maintain it themselves.
• Standard integrations — WhatsApp Business API, Stripe, Airtable, Google Sheets, Slack, email. Make has modules for all of these that work out of the box.
• Time-to-live matters — Make builds ship in days, not weeks. For a client who needs something live quickly, it wins.

The ceiling: Make gets painful when you need complex data transformations, parallel processing, or error handling that goes beyond retries. The visual interface that makes it fast to start makes it hard to reason about at scale.

When we use n8n

n8n is Make for builders who want more control. It's open-source, self-hostable, and handles more complex logic without the visual interface becoming a liability.

We reach for n8n when:

• Volume is high — Make's pricing is per operation. At 50,000+ operations per month, n8n self-hosted is cheaper.
• Custom logic is required — n8n lets you write JavaScript directly in workflow nodes. When you need a complex data transformation, string processing, or custom calculation, you can do it inline rather than reaching for workarounds.
• The client wants to own the infrastructure — n8n runs on their servers. Some clients, particularly in healthcare and finance, need that.

The ceiling: n8n requires more setup, more maintenance, and a more technical client (or ongoing support from us) to keep running. It's not a drop-in replacement for Make — it's a step up in complexity.

When we build custom

Custom code — Python, Node.js, a proper backend — is the right call in fewer situations than most clients assume. We build custom when:

• The integration doesn't exist — If a client uses a niche CRM or ERP with no public API or Make module, we write the integration ourselves.
• The performance requirements are strict — Sub-second response times, high concurrency, or real-time requirements that a polling-based automation tool can't meet.
• The business logic is genuinely complex — Multi-step conditional flows with stateful logic, machine learning inference in the loop, or deeply nested data transformations that would be unmaintainable in a visual tool.
• This is the core product — If the automation IS the product (like ShopTap's WhatsApp commerce layer), we build it properly from the start.

The trap: clients often want custom because it feels more "professional" or "permanent". The actual cost of custom — build time, testing, deployment, maintenance, onboarding — is three to five times higher than a Make equivalent for the same functional outcome. We push back on custom when the use case doesn't justify it.

The actual decision framework

In practice, we ask four questions:

1. Does Make have native modules for all the integrations required? If yes, start with Make unless another condition overrides it.
2. Will this run more than 50,000 operations per month within six months? If yes, n8n.
3. Does the logic require stateful processing, custom algorithms, or sub-second latency? If yes, custom.
4. Is this the core product, or supporting infrastructure? Core product means custom. Supporting infrastructure means a tool.

Most service business automations — intake, booking, payments, notifications — are Make. High-volume operations platforms are n8n. Anything that's the actual product is custom.

The biggest mistake is making the decision based on prestige rather than requirements. The best tool is the one that solves the problem reliably and is maintainable by whoever will own it after we hand it over.