ComparisonChecked 29 Oct 2026
Zapier or Make vs a custom integration: when each fits
Use Zapier or Make when the job is a straight line between two apps they support, the volume is modest and a missed run is cheap to retry. Use a custom integration when the job needs two systems kept in step in both directions, a failure to undo itself across steps, real depth in an ERP, data from a system with no API, or code and data you own. Many businesses use both.
How do they compare, criterion by criterion?
| Criterion | Zapier or Make fits when | A custom build fits when |
|---|---|---|
| Volume | Modest volume, where billing per run stays small. | High or steady volume, where per-run billing grows with every run. Compare the monthly bill with a fixed quote. |
| Branching logic | A few conditions you can draw as paths or routes. | Rules that depend on history or accounting rules, such as checking each invoice against historical patterns before it is finalized (Kintec). |
| ERP and CRM depth | The connector already exposes the records and fields you need. | You need the ERP's own endpoints and posting logic, or two systems that stay in step both ways (Business Central via REST and OData, Brightpearl with HubSpot). |
| Data ownership | You are fine with the workflow and its run history living in the tool's account. | The code, hosting and credentials should be yours. Full ownership transfers at handover, with documentation. |
| Pricing model | Usage-based billing suits you. Zapier counts tasks and Make bills credits. | You prefer a fixed-scope quote, agreed in writing before any code is written. |
| Error handling and rollback | A failed run is cheap to retry or ignore. Both tools offer retries and error handling. | A half-finished run must not leave a half-built record across several systems (Goss RV). |
When is Zapier or Make the better choice?
When the job is one trigger and a few actions between apps the tool already supports, when a missed run costs little, and when you want to change it yourself without an engineer. In that case use the tool: a custom build costs more than it returns.
It is also a sensible way to try a workflow before committing to it. If the workflow proves its worth and starts to strain, such as duplicates appearing, a failed step leaving partial records, or a bill that grows with every run, that is the moment to talk about a custom build.
When is a custom integration the better choice?
- 1Two systems must stay in step, both ways. Aid Through Trade keeps orders, customers and its product catalog in Brightpearl while sales works in HubSpot. HubSpot changes reach Brightpearl in real time through webhooks, Brightpearl data reaches HubSpot in daily jobs, and loop protection stops a note synced one way from coming back as a duplicate. 10,399 contacts were migrated. A one-way trigger would not have needed any of that. Aid Through Trade case study
- 2A failure half-way has to undo itself. The Goss RV deal card builds a quote and sets up two to five installments, each charged through HubSpot's own quotes. If any step fails half-way, the card rolls back, so no half-built quote is left behind. Decide what a half-finished run should leave behind before you build, whichever tool you use. Goss RV case study
- 3The source system has no API. DeMont Family Swim School's enrolment data sat in iClassPro with no API the school could use. A service signs in, pulls the families, students and drop-list reports on a schedule, and syncs linked parent, household and child records into HubSpot. A connector can only use what the source system exposes. DeMont Family Swim School case study
- 4The ERP needs real depth. Kintec's invoicing agent works with Business Central through REST and OData endpoints. It cross-verifies each request, generates the invoice with the correct posting logic, validates it against accounting rules and historical patterns, and finalizes the payment workflow. That removed 70+ hours of manual invoicing a month. Kintec Global case study
These describe what each build had to do. This page does not claim a no-code tool could not have been configured for any of them.
What does each cost?
Both tools bill by usage. Zapier counts a task “whenever Zapier successfully completes a unit of work” and does not count failed actions. Make bills in credits, and most actions use one. Either way the bill follows the number of runs. This page quotes no prices: both change, so read the current plans before you decide.
A custom build is a fixed price, agreed in writing first: after a 15-minute scoping call you get a written quote with fixed scope, timeline and deliverables within 48 hours, before any code is written.
Sources, checked 29 Oct 2026: zapier.com/pricing and make.com/en/pricing. Both pages list branching and error handling: Zapier lists Paths and automatic replay of failed tasks on its Pro plan and above, and Make lists routers and error handlers named Rollback, Break, Resume, Commit and Ignore.
How do I decide?
- 1Does data have to move both ways, and what stops one change from echoing back?
- 2What should a half-finished run leave behind, and who finds out it failed?
- 3How many runs a month, and what does billing per run come to at that volume?
- 4Does the source system expose the records and fields you need, or is there no API?
- 5Who must own the workflow, the code and the credentials a year from now?
If most answers are “no” or “doesn’t matter”, a connector is probably enough. If two or more are “yes”, talk to me about a custom build.
Common questions
Is Zapier or Make enough for a HubSpot integration?
Often, yes, for a simple step between two supported apps. A CRM card is different: it is a custom screen inside HubSpot, built as a HubSpot UI extension rather than as a step between apps. Syncs that must run both ways, roll back or read a system with no API are where the HubSpot builds on this site were custom.
When should I move from Zapier or Make to a custom integration?
Move when failure handling, a two-way sync or the monthly bill becomes the problem, not before. If a zap or scenario runs quietly and a missed run is cheap, leave it alone. The 15-minute scoping call is the place to work out which side your case falls on.
Will you tell me if an off-the-shelf tool is enough?
The site lists cases where an off-the-shelf tool already solves the problem cleanly as not a good fit for a custom build. If that describes your case, using the tool is the better choice and a custom build would cost you more than it returns.
How does pricing work?
Pricing is fixed and agreed in writing before any code is written. After a 15-minute scoping call you get a written quote with fixed scope, timeline and deliverables within 48 hours. A fixed price means the cost is set by that written scope rather than by hours worked, so you know what you are committing to before the build starts. No price list is published, because every project is scoped on its own.
Do I own the code?
Yes, you own what is built. Full ownership transfers at handover, together with documentation and handoff-ready code that your team can keep extending. That means you are not tied to the engineer who built it: your own team or another developer can pick the code up. Handover comes after the production deploy and is followed by a 14-day fix window.
Related pages
- HubSpot integrations — CRM cards, syncs and apps that create deals
- Back-office automation and custom AI agents
- Business Central and ERP automation
- All case studies