Guide

When Zapier, Make, n8n, Power Apps, OutSystems or Mendix fit — and when you need custom software.

By Elias Miles, founder of BlueSail AI · October 9, 2026

We build with n8n and Make.com on real projects, and we write custom code when those tools stop fitting. This page is the honest version of that call: which of the common no-code and low-code platforms is right for which problem, where each one breaks, and the specific signals that tell you a workflow has outgrown the tool it is sitting in.

If the job is moving data between SaaS products you already pay for, a no-code tool is almost always the right answer. If the job has to be exactly right, runs at high volume, has multi-pass logic, or needs a user interface, the no-code tool will cost you more in workarounds, surprise bills and silent failures than a build that fits the problem. Most real businesses end up with both.

Four classes of tool, at a glance

These four categories cover almost every "should we build or buy" conversation. The difference between them is not quality — all four are serious engineering — it is which problem each one is actually built for.

Tool	Best at	Pricing shape	Main failure mode
Zapier & Make iPaaS — glue between apps	Moving records between SaaS products you already pay for. New Stripe charge → row in Google Sheets → Slack message. Hundreds of pre-built connectors do the authentication for you.	Per task (Zapier) or per operation (Make). Cheap at low volume, expensive once a workflow runs thousands of times a day.	Silent breakage. A connector changes, a field renames, a step fails without alerting the right person, and nobody notices until the downstream report is wrong.
n8n Self-hostable workflow engine	The same jobs as Zapier and Make, but with code steps when the no-code node doesn't do what you need, and without per-task fees. Good when you want to own the infrastructure.	Free self-hosted; paid cloud starts around $20/month. The hidden cost is operating it — hosting, upgrades, backups, access control.	The same silent breakage as Zapier, with the additional risk that an upgrade or a self-hosted outage is yours to fix at 2am.
Power Apps, OutSystems & Mendix Low-code application platforms	Internal line-of-business apps for companies that already run on the surrounding platform — Power Apps if you are a Microsoft 365 shop with Dataverse, OutSystems or Mendix if you have an enterprise agreement and in-house developers to run them.	Per-user per-month, often with a floor of several thousand dollars annually before you add seats. The pricing is written for enterprises, not for small firms.	Platform lock-in combined with ceiling costs — the app that cost $20k to build costs $60k/year to run, and the team cannot leave without rewriting from scratch.
Custom code A codebase you own	Software whose core logic is specific to your business, workloads that would be expensive on per-task pricing, and products that need to look like a product rather than a template. Also the right call when the data is sensitive enough that platform lock-in is itself a risk.	A one-time build cost plus ongoing hosting and maintenance. Higher upfront, flat afterwards — the opposite shape to per-task or per-seat pricing.	Scope creep during the build, and a codebase nobody maintains after launch. A written, fixed scope and a maintenance plan are what prevent both.

What each tool is actually for

Zapier & Make

iPaaS — glue between apps

Where it fits.: Moving records between SaaS products you already pay for. New Stripe charge → row in Google Sheets → Slack message. Hundreds of pre-built connectors do the authentication for you.
Where it breaks.: Anything with branching logic more than two levels deep, anything that must be exactly right every time, and anything high-volume. Per-task pricing turns steady workloads into surprise bills.
What it costs.: Per task (Zapier) or per operation (Make). Cheap at low volume, expensive once a workflow runs thousands of times a day.
We reach for it when:: Low-stakes glue — notifying people, moving data between tools, triggering a build from a form submission. The jobs where 'close enough' is actually fine.

n8n

Self-hostable workflow engine

Where it fits.: The same jobs as Zapier and Make, but with code steps when the no-code node doesn't do what you need, and without per-task fees. Good when you want to own the infrastructure.
Where it breaks.: User-facing software. It is a workflow engine, not an app platform — if your team or your customers need to log in and do something, n8n is not that layer.
What it costs.: Free self-hosted; paid cloud starts around $20/month. The hidden cost is operating it — hosting, upgrades, backups, access control.
We reach for it when:: Automation at volume where Zapier's per-task pricing would run away, and where the client wants the workflows to live on their own infrastructure.

Power Apps, OutSystems & Mendix

Low-code application platforms

Where it fits.: Internal line-of-business apps for companies that already run on the surrounding platform — Power Apps if you are a Microsoft 365 shop with Dataverse, OutSystems or Mendix if you have an enterprise agreement and in-house developers to run them.
Where it breaks.: Public-facing products, apps that need to look and feel like your brand rather than the platform's templates, and anything with calculation logic the platform's expression language cannot cleanly express. Portability is also poor: you cannot take an OutSystems app and run it somewhere else.
What it costs.: Per-user per-month, often with a floor of several thousand dollars annually before you add seats. The pricing is written for enterprises, not for small firms.
We reach for it when:: We do not. When a client is already standardized on the Microsoft stack, Power Apps is sometimes the right answer and we will say so, but we do not build on these platforms ourselves.

Custom code

A codebase you own

Where it fits.: Software whose core logic is specific to your business, workloads that would be expensive on per-task pricing, and products that need to look like a product rather than a template. Also the right call when the data is sensitive enough that platform lock-in is itself a risk.
Where it breaks.: Problems a product already solves well. If Stripe, QuickBooks, HubSpot or Google Workspace already does the job, custom code is the expensive answer to a solved problem.
What it costs.: A one-time build cost plus ongoing hosting and maintenance. Higher upfront, flat afterwards — the opposite shape to per-task or per-seat pricing.
We reach for it when:: Core business software — commission engines, investor portals, marketplaces, analytics platforms — where the rules are specific and the volume is high enough that per-task pricing would not survive.

Six signals the no-code tool has stopped fitting

None of these on its own means custom code is the answer. Two or three of them together is a strong signal the tool is being used for a job it was not built for.

1. You are routing through a no-code step to work around its limits

Two Zaps that trigger a third because one Zap could not do the whole thing. A Make scenario that calls a webhook into a tiny custom API because the Make nodes could not do the calculation. These are the shape of a tool outgrown.

2. The per-task bill is now a meaningful line item

A workflow that costs $40/month at launch costs $900/month a year later. At that point, hosting a small custom service is often less than one month of what you are already paying.

3. The output has to be exactly right, every time

Commission calculations, payroll, financial reports, legal documents, anything a regulator or an auditor will read. These do not survive a silently dropped step, and the no-code tools do not give you the test coverage that catches silent drops.

4. The logic depends on multiple passes over the same data

A manager's commission override cannot be calculated until every representative they supervise has had their individual numbers finalized. A partnership distribution has to split revenue before each person's rate applies. These second-pass dependencies are hard to express cleanly in a no-code flow.

5. A user needs to log in and do something

A workflow engine moves data in the background; it is not where a user clicks around to review exceptions, approve a payout, or download a report. The moment the problem has a UI, you are looking at a different class of tool.

6. The data is more valuable than the tool it sits in

If being locked into the platform is itself a risk — because the data would be painful to move, or because the platform could change its pricing or its product and leave you with no recourse — the no-code tool is a liability wearing the costume of a convenience.

The option most comparisons skip: use both

Framing this as no-code versuscustom code is usually the wrong frame. The no-code tools are extraordinary at connecting SaaS products. Custom code is extraordinary at owning logic that has to be exactly right. The right architecture usually uses each one where it is strong and does not try to make either one do the other's job.

Zapier moves inbound form submissions into your database; a custom service handles the actual lead scoring and routing.
Make.com drops Stripe charges into your accounting software; the custom-built billing portal is where customers manage their subscriptions.
n8n runs the overnight data syncs between systems; the custom-built web app is where staff work with the data during the day.
A low-code admin panel handles internal CRUD on a database; the customer-facing product that reads from that database is custom.

A custom build does not have to replace the no-code tools you are already paying for. It usually sits beside them and owns the one or two steps they cannot do.

A real example: a workflow Zapier, Make and OutSystems could not do

A wealth management firm with $1.5 billion in assets ran its commissions on an aging desktop portal. The surface problem looked like a Zapier job: clearing-firm files arrive daily, numbers need to land in payroll. The real problem was underneath.

Brokerage compensation runs on small, specific rules that interact. A representative might have a temporary rate for one period. A partnership might split revenue three ways unequally before each member's individual rate applies. A manager's override income depends on the final gross revenue of every representative they supervise — which means it cannot be calculated until the first pass is finished. Ticket charges follow tiered logic that behaves differently for small-gross and zero-gross cases. None of these rules are complicated alone. All of them have to run together, correctly, every month, without exception.

That shape is why the off-the-shelf replacement they found cost $4,500 per month and still needed a specialist to run. It is also why Zapier or Make could not have done this: there is no clean way to express a second-pass calculation that depends on the first pass's totals in a visual flow, and the per-task pricing on the file volume would have been a running bill of its own. A low-code platform like OutSystems could have built the UI, but the compensation engine would still have been custom work inside it, at platform floor pricing on top.

We built Dropzone around the firm's actual rules. It is live, it is the firm's primary system for commission calculation and payroll, and it removed the hour of daily manual processing and the $4,500-a-month alternative.

Read the full Dropzone case study →

Five questions to decide

Is the hard part of this problem the integration between tools, or the logic that runs after the data arrives? If it is the integration, start with no-code. If it is the logic, start with code.
What does this cost at 10x the current volume? Add it up at the pricing page's own numbers before you commit.
If this breaks silently at 2am, who finds out, and how? If the answer is 'nobody until the next morning,' the tool is wrong for the job.
How much of the business lives inside this workflow? The more of the business, the worse platform lock-in becomes.
Could a small custom piece sit beside the no-code setup and own the one step it cannot do, rather than replacing the whole thing?

If the honest answers point at a workflow outgrowing its tool, building a small custom piece beside the no-code setup is almost always cheaper than replacing it. Replace the no-code platform wholesale only when its failure modes are costing more than it is saving.

Frequently asked questions

Should I use Zapier or build custom software?

If the job is moving records between SaaS products you already pay for and the volume is modest, use Zapier. If the job has branching logic, has to be exactly right, runs at high volume, or needs a user interface, Zapier will cost you more in workarounds and surprise bills than a custom build. Most real businesses end up with both — Zapier for the glue, custom code for the parts that have to be right.

What is the difference between Zapier, Make and n8n?

They do the same thing — connect SaaS products through visual workflows — with different tradeoffs. Zapier has the most connectors and the simplest editor; Make is cheaper per operation and better at branching logic; n8n is self-hostable and lets you drop into code when the no-code node does not do what you need. If you are already running at the volume where Zapier's bill matters, Make or n8n is usually a better fit for the same work.

When does Power Apps, OutSystems or Mendix make sense?

Power Apps makes sense when the company is already standardized on Microsoft 365 and Dataverse, and the app is internal. OutSystems and Mendix make sense inside enterprises with an existing low-code practice and the budget to run it — floor pricing on both is written for companies with hundreds of users. For a small or mid-size firm building a public-facing product, custom code is usually cheaper and much more portable.

Can a custom build replace a Zapier or Make setup entirely?

Usually not in one step, and often not at all — the right pattern is to keep the no-code tool for what it does well and build custom code only for the parts that have outgrown it. That is cheaper than a wholesale rewrite and keeps the pre-built connectors doing their job. Replace the no-code stack entirely only when its failure modes are costing more than running the no-code platform saves.

What is the real cost of switching from no-code to custom code?

Add up the build, the hosting and the maintenance of the custom piece, then subtract what the no-code setup is costing today — the subscription, the per-task fees at current volume, the hours lost to silent failures, and the hours lost to workarounds built around the tool's limits. The switch is almost always wrong at low volume and almost always right at high volume. The hard case is the middle, where the five questions above are what the answer turns on.

Do you build with Zapier, Make or n8n yourselves?

Yes. We use n8n or Make.com on projects where the volume is manageable and the logic fits what they do well. We write custom code when the logic is too specific, the volume is too high for per-task pricing, or the output has to be exactly right. We tell clients which one we are reaching for and why before we build.

Not sure where your workflow sits?

Tell us what the no-code setup is doing and where it is starting to creak. We will tell you honestly whether to keep it, build a small piece beside it, or replace it.

Talk to us Custom vs off-the-shelf Process automation