# Build vs Buy Integrations and Which Tools to Buy
By Ossian Kettunen · 2026-11-15 · Source: https://www.activepieces.com/blog/build-vs-buy-integrations-and-which-tools-to-buy
---
Build vs buy integrations is the decision between coding and maintaining connections yourself and paying a platform for them, whether that platform is a managed service or an open-source tool like [Activepieces](https://www.activepieces.com).
The answer is to code only the connections that are your product or your edge and buy the rest.
## Build versus buy integrations shortlist
### The two-sentence answer
Write code for the integrations customers pay you for or competitors can't copy, and buy everything else. Which purchase fits depends on who will maintain the workflows and whether data may leave your network, not on how many connectors a vendor advertises.
**The catalogue page is not the test**. That second test matters more.
A platform that lists thousands of apps may give you a trigger with no field you need, or an action that can't write to the object you care about. Check the specific trigger and the specific field mapping before you count anything.
Take the seven realistic starting points as splitting along maintainer and data-location lines, not along size. The shortlist below is one pick per line, with who it's for.
- Code, for core integrations that are your product or your edge, owned by engineers
- Zapier, for non-technical staff who want hosted, quick single-purpose automations
- Make, for ops people who want a visual builder with branching and data handling in the cloud
- n8n, for technical teams that want to self-host or run flows with code steps
- Workato, for central IT teams running governed, enterprise-wide automation
- Power Automate, for organisations already standardised on Microsoft 365
- [Activepieces](https://www.activepieces.com), for teams that want open-source automation they can run on their own infrastructure or in the cloud
Next comes the test for choosing among these, starting with who touches the workflow after launch.
This covers internal and operations workflows:
- moving records between your CRM, ticketing, billing, chat and spreadsheets
- routing approvals
- syncing data your own staff use
It does not cover customer-facing integrations you ship inside your own product, such as a "Connect your account" feature. Those are usually your product, so the build side of the argument applies to them by default and gets little space here.
### How integration tool prices were checked
Because vendors change tiers and quotas often, plan details and limits were checked against each vendor's own pages in November 2026. Confirm the current plan and the limit that matters, such as task caps or self-hosting terms, on the vendor's page before you commit.
Where this article gives no price, it is because none could be confirmed, and none has been guessed.
## Six criteria that decide build versus buy
Judge every option on the same six criteria, and **the answer follows from who maintains the flows** and whether data may leave your network, not from connector counts.
The list below is the checklist applied to each option in this article, and the first line you fail usually settles the rest.
- Apps to connect
- Who maintains the flows
- Self-hosting versus cloud
- SSO, roles and audit logs
- Approvals and error handling
- Pricing model and cost at your size
### Connectors and who maintains them
Count only the apps you use, and the exact triggers and actions you need on each. A catalogue of thousands is worthless if the one action you need, such as updating a single field, is missing.
If nobody on your team writes code, every custom connector becomes a ticket in someone else's queue.
$400 to $1,000 is what [Codexify Solutions](https://www.codexifysolutions.com/blog/how-much-does-custom-api-integration-cost) puts on building a simple connector, so the API call itself is cheap and the real cost is keeping it working.
If data may not leave your network, cloud-only tools drop out before features are compared.
Check whether SSO, role permissions and audit logs come with the plan you would actually buy, because they're often reserved for higher tiers. A tool that lacks them forces your security reviewer to say no later.
Ask what happens when step four of seven fails: does it retry, alert someone, and let you replay that run? Ask also whether a human approval can pause a flow.
Even the lowest-cost sync project exceeds the highest-cost workflow. Codexify prices a business workflow at $1,500 to $4,000 and **a multi-system sync at $5,000 to $12,000**, which means organizations must treat these as capital investments rather than routine software purchases.
The jump between them is why error handling is the line to question in any quote.
### Integration tool pricing model and cost at scale
Calculate with your own monthly run count, because per-task, per-run and flat pricing diverge sharply as volume grows.
On the build side, Codexify's top range, enterprise legacy work at $15,000 to $40,000, is only the upfront bill, so the implementation unfolds across multiple phases with additional costs.
API-change upkeep and on-call time recur and sit outside those figures. The chart below sets the four build ranges side by side, and the options that follow are measured against them.
## Comparison table: price, strength, limit and best for
Lined up against those build ranges, each option gets the same five columns in the table. The one price I could source across platforms is what a 5,000-run month costs, checked in November 2026.
| Option | Entry price (checked Nov 2026) | Pricing unit | Strength | Limit | Best for |
|---|---|---|---|---|---|
| Build in-house | No list price; engineering time | Developer hours | Matches your data model and permissions exactly | You own every API change, retry and token refresh | The integration that's your product or edge |
| Zapier | $283.50/month at 5,000 runs | Tasks | Large app catalogue, fast setup | Cost climbs steeply with volume | Non-technical teams, low volume |
| Make | $32/month at 5,000 runs | Not published in sources checked | Visual builder with branching | Large scenarios get hard to read | Mid-volume flows built by ops staff |
| n8n | $60/month at 5,000 runs | Not published in sources checked | Code nodes and a self-hosting option | Self-hosted, someone must run and patch it | Technical teams with data-residency limits |
| Workato | Not published | Not published | Enterprise governance and admin controls | Price is quote-only | IT-run, cross-department automation |
| Power Automate | Not published in sources checked | Per user or per flow | Tight fit with Microsoft 365 | Value drops outside the Microsoft stack | Microsoft-centred organizations |
| Activepieces | $20/month at 5,000 runs | Not published in sources checked | Lowest 5,000-run cost of the four charted | Only the 5,000-run figure is compared here | Cost-sensitive, high-volume flows |
Only four platforms have a sourced 5,000-run figure, so the cost chart below plots those. According to [StackPrice on dev.to](https://dev.to/stackpricedev/what-the-free-plans-of-11-automation-and-ai-agent-tools-actually-include-nov-2026-2kop), [Activepieces](https://www.activepieces.com) costs $20 a month at that volume and Make costs $32, prices that circumvent procurement delays.
n8n costs $60, and Zapier costs $283.50, putting Zapier out of reach for organizations optimizing for cost.
Most teams would eliminate Zapier on cost grounds alone: it costs roughly 14 times the Activepieces figure and about nine times Make's for the same 5,000 runs, leaving no economic justification for the premium.
If your flows run in the thousands, the pricing unit matters more than the connector count. A cheap entry plan tells you little once volume arrives.
Three options have no figure on the chart: Workato, Power Automate and the build option. Compare them on who maintains the flows and where data may travel, as the next part does.
## Each option judged against the same criteria
When judged on who maintains the flows and where data may travel, each option wins a different job. Code is for integrations inside your product, Zapier for breadth, Make for visual complexity, n8n for technical self-hosters, Workato for governance, Power Automate for Microsoft estates.
I've left out dates and prices here because I have no confirmed figures to cite.
### Build in-house
With in-house code, your engineers own everything: OAuth token refresh, webhook signature checks, retries, rate-limit backoff and every upstream API change. Data never leaves your network unless you send it.
That cost is worth paying for integrations customers see as your product, or ones that encode your edge. It's poor value for a Slack notification.
### Zapier
Because Zapier is a cloud-only service, data always passes through its infrastructure. Non-engineers can build and maintain Zaps, and its app catalogue is the widest of the group.
Branching exists through Paths, but long multi-branch logic gets awkward. Judge it on whether the specific trigger and action you need exist, not on the catalogue headline.
### Make
For an operations person who thinks in data shapes, Make fits: it builds scenarios on a visual canvas, with routers, iterators and aggregators that make branching and looping visible. It's a hosted product, so the data-residency question is answered by Make's cloud, not by you.
### n8n
If you self-host n8n, execution stays inside your network, and its Code node accepts JavaScript or Python. That favours teams with someone comfortable running servers. Its licence is fair-code rather than open source, so read the terms before embedding it in something you resell.
### Workato
When governance is the requirement, Workato is the pull: it runs recipes with role-based access, audit logging, and managed promotion of recipes between environments.
For systems behind a firewall it has an on-premises agent. Expect it to be run by an IT or integration team rather than by individual business users.
### Power Automate
Inside a Microsoft tenant, Power Automate runs cloud flows with sign-in through Microsoft Entra ID and data loss prevention policies that limit which connectors can touch each other. Its on-premises data gateway reaches internal systems.
It fits tenants already built on Microsoft 365 and Dataverse. Outside that estate, the connectors you need may sit behind premium licensing.
## Where Activepieces fits and where it does not
Activepieces fits teams that build their own flows from a shared set of 750 integrations, counted from its open source monorepo, and want to see every step, so integration failures **are resolved immediately without waiting on vendors**.
It loses where the job is a long-tail app catalogue or heavily governed enterprise integration.
### Where it ranks and where it loses
On the criteria that matter here, who maintains the flows and where the data goes, Activepieces ranks well for an ops team with one technically inclined owner: the core is MIT-licensed and can run on your own servers, and every plan, including the free one, allows unlimited flows.
Each step is a visible node, each run is listed under Runs, and Versions lets you see what changed before you publish.
When the people maintaining flows aren't technical and the apps are obscure, Zapier wins. Its catalogue is the thing to buy it for, though a long list of connectors says little until you check that the specific trigger and action you need exist.
Workato wins in large estates where governance, audit and central control outrank build speed.
Self-hosting is where governance usually gets cut, because the on-premises build ships without the controls.
Activepieces does not split the product that way: the air-gapped self-hosted docs and the managed cloud, which can be pinned to an EU or US region, describe the same enterprise controls, namely single sign-on, SCIM provisioning, custom roles, audit logs, release management and secret managers.
The core is MIT-licensed, while the enterprise directories under `packages/ee/` carry a separate commercial licence. MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.
If your integrations are mostly with one vendor's suite, that vendor's own tooling probably beats all of us.
### Worked workflow: an approved request routed across apps
Start with a Schedule trigger named "Every Hour" with weekends switched off, as the builder below shows.
The node selector lists spreadsheet integrations such as Google Sheets and Microsoft Excel 365 with actions like Find Rows and Update Row.
Switching weekends off means a request approved on Saturday waits until the next weekday run, which is a deliberate trade for a team that doesn't want weekend noise.
Those actions are enough for an ops intake flow, with the sheet acting as the request queue:
1. The Schedule trigger fires on the hour.
2. Find Rows in Google Sheets returns requests whose approval column a manager has marked approved and whose routed column is still empty.
3. Insert Row writes each approved request into the destination sheet the downstream team works from.
4. Update Row marks the original row as routed, so the next run doesn't pick it up again.
Nothing here pauses mid-run to wait for a human, and that's the limit of this design. Approval happens outside the flow, in the sheet, by a person.
Errors surface in Runs, where a failed step shows where it stopped. The routed marker means a rerun after a failure picks up only the unfinished rows.
An hourly schedule with weekends off comes to roughly 520 runs a month, and a run is 1 credit however many steps it has, so this flow fits inside the 1,000 credits a month on the free plan of Activepieces Cloud.
## Build versus buy decision rule
**Buy a platform for every integration that's plumbing, and build only the ones that're your product or your edge, or that handle data which can't leave your network.**
### Build versus buy rule in one paragraph
When a customer pays for it, or when it gives you something competitors can't copy by buying the same tool, an integration is worth building.
Syncing a form submission into a CRM, posting a Slack alert, or copying a row into a spreadsheet is commodity work, and writing it yourself buys you a maintenance burden and nothing else.
Two conditions then decide which purchase fits. If the people maintaining the flows are non-developers, you need a builder they can read and edit without a ticket. If the data may not leave your network, you need a self-hosted option, whatever the catalogue looks like.
Syncing a form submission into a CRM, posting a Slack alert, or copying a row into a spreadsheet is commodity work, and writing it yourself buys you a maintenance burden and nothing else.
You learn neither from a long connector list. Check the specific trigger and action your workflow needs, because a connector that only offers "new record" and no "updated record" trigger won't do your job.
### Build versus buy checklist for Monday
Do these steps in order, because each one feeds the next; they take you from an unsorted pile of scripts and zaps to a decision backed by one working flow.
1. Inventory every integration you run, including the scripts, the scheduled exports, and the automations someone built in a tool and left. Write down for each one the system it reads from, the system it writes to, who maintains it, and what data it carries.
2. Tag each one core or commodity. Core means it's your product, your edge, or it moves data that must stay inside your network. Everything else is commodity. If you hesitate over a tag, ask whether a competitor using the same off-the-shelf tool would lose anything. If not, it's commodity.
3. Shortlist two platforms against your commodity list. Judge both on the same questions: does it have the exact triggers and actions your flows need, can the person who maintains them work in it, and can it run where your data rules require?
4. Trial one real workflow, not a demo. Pick a commodity integration from your inventory that someone currently babysits, rebuild it on one shortlisted platform, and watch how it handles a failed run. Then repeat on the second if the first leaves doubts.
Run that trial and you have the evidence the catalogue page can't give you. When it holds up, move the rest of the commodity list over one flow at a time and leave the core integrations in your own code.
Roughly 60% of the 750 integrations listed at https://www.activepieces.com/integrations are community-contributed, so check that the specific trigger and action your trial workflow needs exist in the integration before you rebuild it.
## Frequently asked questions
If the integration is your product or your edge, building is cheaper. It's also cheaper when the system on the other end is so specific that no platform's action covers the field mapping you need.
For a generic "new row, send message" flow, you pay engineering time to rebuild what a connector already does, then keep paying every time the vendor changes its API.
## Moving from platform to custom code
Yes, and it's often the cheaper order. A running flow documents the triggers, field mappings and error cases you would otherwise have to guess at.
Move to code only the flows that hit a limit, such as latency or unusual authentication. Leave the rest where they are.
## Automation platform or embedded integration platform: what differs?
An automation platform serves your own team's internal workflows. An embedded integration platform lets your customers connect their own accounts to your product, so it ships inside your app and carries your branding. Ask who owns the connection: your staff, or your end users.
## Self-hosting automation cost versus cloud
Usually yes, in people time rather than licence fees. You take on upgrades, backups, secrets handling, uptime and scaling.
Self-hosting pays off when data may not leave your network. Check the licence too: n8n's Sustainable Use License allows internal business use but restricts offering the software to others as a service.
## Revisiting build versus buy decisions
**Revisit it when something concrete changes**: a flow becomes core to your product, the person maintaining workflows leaves, a new data residency rule applies, or pricing at your volume shifts.
A fixed calendar review mostly produces churn. A trigger-based review catches the moments when the original reasoning stops holding.
## Related reading
- [Workable API Access Tokens for Integrations (2026)](https://www.activepieces.com/blog/workable-api-access-tokens-for-integrations-2026)
- [Activepieces Integrations List for 2026, by Category](https://www.activepieces.com/blog/activepieces-integrations-list-for-2026-by-category)
- [FedRAMP Authorized Vendor List for Secure Integrations](https://www.activepieces.com/blog/fedramp-authorized-vendors-list-2026-integration-guide)
## References
- [dev.to (StackPrice)](https://dev.to/stackpricedev/what-the-free-plans-of-11-automation-and-ai-agent-tools-actually-include-nov-2026-2kop)
- [Codexify Solutions](https://www.codexifysolutions.com/blog/how-much-does-custom-api-integration-cost)