"Can you share a first pass or a framework on how to think about it?"
That's a line from a client sponsor's email a few weeks ago, asking how to reason about middleware costs and the resources needed to maintain a custom integration. It's a fair ask, and I realized we'd never written the answer down, even though we make this call on nearly every project. So here it is, built from two decisions we made in September with two very different clients.
The first client, a healthcare staffing company, needed their applicant tracking system talking to HubSpot. Option A was the native app plus a data share: no code, maintained by the vendor, up in days. Option B was custom middleware on a cloud runtime: full control over transformation, but their small dev team would own it. They chose B because the native app couldn't transform data, and their source data wasn't clean. It also hit the vendor's daily API rate limits, which we knew because a previous attempt to sync notes through it had already failed. Option A was cheaper and would have failed for known reasons.
The second client, a multi-division manufacturer, is going the other way for most of their stack: native connectors and a nightly file feed where those hold, custom code only where a quoting tool keys everything to ERP customer numbers and nothing native can match them. Same framework, opposite answers.
Does the native app carry the fields you actually care about? Lookup fields that reference other tables, custom revenue buckets, anything non-standard: check each one by name before assuming. Half the "native didn't work" stories I hear are really "native didn't sync the three fields sales needed."
Can it transform data, or only move it? If your source data needs cleaning, mapping, or merging on the way in, a mover won't do it, and you'll end up cleaning in the CRM forever.
What are the rate limits versus your volume? Vendors publish them. Multiply by your record counts and the sync frequency you need. If the math doesn't work on paper, it won't work in production.
What happens on the second event? Native apps that write to contact properties often overwrite on every update. If you need history, you need something that writes to a custom object or a timestamped event instead.
Who maintains it at 2 a.m.? A native app is the vendor's problem. Middleware is somebody's, and if that somebody is a two-person dev team, the honest scope includes enablement sessions and a configuration screen so they can own it without reading the code.
If the native app passes all five, use it, and don't let anyone talk you into custom code for elegance. If it fails on fields or transformation, go custom and budget the maintenance explicitly. If it fails only on rate limits, look for a batching approach before writing middleware. And if it fails on the second-event question, the fix is a data model decision, not a build decision, and you should make it before choosing either path.
The case for "always go native" is real: vendor-maintained, upgraded for free, and no one on your team has to remember how it works. The case for "always go custom" is real too: you control every field and every transformation. Both are wrong as defaults. The five questions are the whole method.
If you're mid-decision, run the five questions on your integration and tell me which one it failed. I'm curious whether the pattern holds outside our client base.
This came out of a client project. The story behind it, and what to check in your own portal, goes to subscribers on Thursdays. Get Thursday's note.