- ·The build estimate is not wrong about the happy path. It is wrong because auth edge cases, rate limits, partial failure, and per-customer quirks live outside the documentation, and maintenance has no completion date at all.
- ·No-code platforms like Make, Zapier, and n8n are the right answer for low-volume, mostly linear workflows owned by an operations person. They turn expensive at high volume, at deep error handling, or when nobody can review what changed.
- ·Do not hire an outside team if the integration is your differentiator, if your own engineers have capacity for one or two connections, or if there is no named person to hand the work back to afterward.
You need a handful of integrations shipped this quarter, and the real question is not which API to call. It is who does the work. You can put it on your own engineers, buy a platform that promises the connectors already exist, or hand it to an outside team. Each of those is right in some situations and expensive in others, and the wrong choice does not announce itself for about six months. This is the framework we use when a technical leader asks us to help decide, including the cases where the answer is that they should not hire anybody. We sell integration work, so read the last two sections with that in mind and check the reasoning rather than the conclusion.
The three options, stated honestly
In-house means your own engineers own the code, the on-call rotation, and the domain knowledge. The money cost is salary. The real cost is attention: every hour an engineer spends on a webhook signature is an hour not spent on the product only you can build. A platform means an embedded iPaaS or a unified API vendor, or a no-code tool further down the stack. The money cost is a per-connection or per-customer fee that scales with your success. The real cost is that you inherit somebody else's model of the systems you connect to. An outside team means contracted engineers who build and hand back. The money cost is a day rate that looks high next to salary. The real cost is context transfer, twice: once when they arrive and once when they leave. None of these is cheap. They fail differently, and that is the only thing making this decision tractable.
Why the build estimate is almost always wrong
Ask an engineer to estimate an ERP integration and you will usually hear two weeks. That number is honest. It is the time to make the happy path work: authenticate, pull a list of records, map the fields, write them somewhere. It is also roughly a third of what the integration will take, because the estimate is scoped against the documentation while the work is scoped against how the API actually behaves. The docs say the token lasts an hour. They do not say the refresh endpoint returns a 200 with an error in the body once a tenant admin has revoked consent. The gap between those two sentences is where integration projects go over. We broke down where the hours really go in what an integration actually costs. The short version: the first version of an integration is cheap, and the version that survives contact with production is not.
- 1 Auth that breaks in undocumented ways
OAuth refresh is the easy part. The hard part is the tenant that revokes consent, the sandbox with a different token lifetime than production, the customer still on a legacy API key scheme, and the IP allowlist nobody mentioned until go-live day. - 2 Pagination, rate limits, and the backfill
Syncing the last 30 days is a loop. Backfilling four years of history against a limit of two requests per second is a project: it needs checkpointing, resumability, and a way to run without starving the live sync of quota. - 3 Partial failure, which is the normal case
The job dies after writing 400 of 900 records. What happens on the retry decides whether your customer sees duplicates. That means designing for replay from the start, as in idempotent integrations, not bolting it on after the first incident. - 4 The long tail of customer-specific quirks
One customer has a required custom field. Another renamed the status values. A third runs a version two releases behind. Each is a small change, and together they are why integration code keeps growing for years after it was declared done. - 5 Maintenance, which never ends
Both sides keep moving. Their API deprecates a field, your data model gains a column, a sandbox certificate expires on a Saturday. Nobody puts this line in an estimate because it has no completion date, which is exactly why it dominates the total.
When no-code is genuinely the right answer
Zapier, Make, and n8n get dismissed by engineers for the wrong reason, which is that they are not code. The useful question is volume and branching. If a workflow is low volume, mostly linear, and owned by an operations person who wants to change it without filing a ticket, a no-code platform is not a compromise. It is the correct answer, and building it yourself is the expensive mistake. A form submission that creates a CRM record, notifies a channel, and files a row in a sheet does not need an engineer, a deploy pipeline, or a code review. It needs to work on Tuesday and be editable on Wednesday. n8n earns a specific mention because it is self-hostable, which removes the data residency objection that rules out hosted tools in regulated environments, and it drops to plain JavaScript in a node when one step outgrows the visual editor.
When no-code becomes the expensive option
The switch flips on three signals. First, volume: per-task pricing is fine at a thousand runs a month and painful at two million, and the platform bill starts to resemble an engineer's salary with none of the leverage. Second, error handling: visual retry settings are shallow, and once you need conditional replay, dead letter handling, or a reconciliation pass that compares both sides and repairs the difference, you are writing code inside a tool that is bad at holding code. Third, review: a 60-node scenario built by three people over two years has no diff, no test suite, and no way to answer what changed last Thursday. That third one usually forces the migration, and the migration is harder than the original build would have been, because the logic now lives in a canvas nobody documented. Watch for the scenario everyone is afraid to touch.
Where a unified API layer helps, and where it hides the field you need
A unified API gives you one schema across many vendors: one contact object across a dozen CRMs, one employee object across nine HR systems. When your use case really is the common denominator, that is a large win and you should take it. Reading contacts, listing employees, pulling invoice headers: buy that, do not build it. The failure mode is worth naming precisely. Unified schemas cover the intersection of what every vendor supports, and the field that matters to your product is often outside that intersection. It is a custom field, a workflow state, an approval chain, a line-item tax code. Vendors know this and offer passthrough requests, which is a polite way of saying you write vendor-specific code anyway, through an extra hop, with thinner docs and worse errors. Before committing, take your three hardest real requirements and test them against the schema rather than the marketing page.
The maintenance question nobody scopes
Every integration proposal has a build number and no maintenance number, and that omission is the largest source of surprise in this whole decision. A connection in production is not free during the months when nothing happens, because something eventually does: a vendor ships a breaking change, a customer's admin rotates a credential, a schema drifts and the sync writes wrong values for two days before anyone notices. Multiply the quiet cost by the number of connections and you have the actual staffing question. Six integrations is not six build projects. It is a standing part-time job with no end date, and it lands on whoever built them unless you decide otherwise on purpose. If the integration feeds an agent that takes actions rather than a dashboard a human reads, the bar rises again, because a silent data error stops being a bad chart and becomes a wrong action. That failure mode is the subject of connecting agents to ERP systems.
When not to hire an outside team
We turn work down for three reasons, and they are the same three you should use to filter us out before the call. First, if the integration is core to what makes your product different, keep it in house. If you sell a warehouse system and the WMS connector is why customers pick you, that knowledge belongs to your engineers permanently, so pay the learning cost. Second, if you already have engineers with capacity and the scope is one or two connections, hiring anyone is overhead, because the context transfer costs more than the code. Third, if you have nobody to hand it back to, do not start. An outside team that builds six integrations and leaves has given you six things to maintain and nobody who understands them, which is worse than the four you would have built yourself. The honest case for outside help is narrow: more connections than you can hire for, work that is not your differentiator, and a named owner waiting.
A short decision checklist
- 1 Count connections, not projects
Three integrations for one customer is a project. Three integrations across forty customers with their own configurations is a product surface that needs versioning, per-tenant config, and observability. Never scope the second as though it were the first. - 2 Name the maintainer before the first commit
Write down which specific person owns this connection twelve months from now. If that answer is unclear, no option on this page works, and fixing it matters more than choosing a build approach. - 3 Test the hardest requirement, not the demo
Take your three most awkward real requirements into a platform trial or a unified schema. Anything can move a contact record. The decision gets made by the custom field and the failure case. - 4 Try the boring option first
Build one integration the cheapest way that could plausibly work, usually a no-code scenario or a hundred lines in a repository you already run. You will learn more about the target API in a week than any evaluation gives you, and the estimate for the next five becomes real.
There is no default answer. Low volume and operations-owned goes to no-code. Common-denominator reads go to a unified API. Anything that defines your product stays with your engineers. Outside help earns its place only when you need several connections faster than you can hire and somebody is ready to own them afterward. Whichever you pick, write the maintenance number down before you start, because that is the cost that decides whether the choice was right.
