The System Integration Decision Framework: Build, Buy, or Glue
Every integration eventually outgrows the tool that built it. Here is the framework for picking the right starting point — and the signals that tell you when to migrate.
14 min read · Published May 16, 2026
Why the integration decision is harder than it looks
Mid-market companies face a peculiar problem with integrations. The space has four legitimate categories of solutions — pre-built connectors, no-code platforms, iPaaS, and custom code — each with vocal advocates and real strengths. Picking wrong has compounding consequences: the integration that took two weeks to ship with the wrong tool can take six months to migrate off later.
Most decisions get made on factors that are easy to measure (price tag, time-to-first-version) and ignore factors that matter more over a 3-year horizon (observability, complexity ceiling, vendor lock-in, ability to debug at 11 PM). This guide is the framework for making the call with the right inputs.
The honest reframing
Most integration debates frame this as a one-time choice. It isn't. Almost every mid-market company ends up with a mix of all four categories, and the real skill is putting each integration in the right bucket — not picking one platform to rule them all.
The four categories of integration solutions
Pre-built connectors
Vendor-provided integrations between two specific systems (Stripe's HubSpot integration, NetSuite's Shopify connector). Fast to enable, limited to what the vendor decided to expose. Often opaque when they fail — you are debugging the vendor's code without source access.
No-code platforms (Zapier, Make, n8n)
Visual workflow builders. Excellent for simple trigger-action automations, especially when business users need to iterate without engineering involvement. Cost scales with task volume; debugging beyond the platform's surfaces is hard.
iPaaS (Workato, Boomi, MuleSoft, Tray)
Enterprise integration platforms with broader capabilities than no-code — orchestration, transformation, governance, monitoring. Five-figure annual minimums; appropriate when you have multiple workstreams justifying the platform overhead.
Custom integration code
Engineering-built integrations in your codebase, deployed on your infrastructure. Highest ceiling for complexity, observability, and ownership. Slowest to first version, lowest cost at scale, fully under your control.
The decision matrix: which category fits this integration
Not every integration needs the same treatment. Run each candidate through these five questions, then map to the recommended category.
1. How load-bearing is this integration?
If silent failure has real business cost (lost revenue, data corruption, compliance violation), you need observability and ownership — custom code or iPaaS. If silent failure means someone fixes it manually later, no-code or a pre-built connector is fine.
2. How complex is the logic?
Simple trigger-action (when X happens, do Y in another system): pre-built or no-code. Branching, loops, state, transformations, retries: custom code or iPaaS. If you cannot draw the logic on a whiteboard in 60 seconds, you have outgrown no-code.
3. What is the expected volume?
Under a few hundred events per month: any category works. Hundreds per day: no-code becomes expensive, pre-built connectors are usually fine. Thousands per day: custom code or iPaaS — no-code task-based pricing will hurt.
4. Who will own it long-term?
Business team that needs to iterate: no-code or pre-built. Engineering team: any category, but custom usually wins for the leverage and ownership. Nobody is clearly the owner: do not build it yet — find an owner first.
5. What is the 3-year cost profile?
Pre-built: low subscription, sometimes free. No-code: cost scales with volume, often surprising at year 2-3. iPaaS: five-figure annual commitment, predictable. Custom: high upfront, low ongoing. Run the math at expected year-3 volume, not year-1.
Common patterns: what each category fits well
Pre-built connector wins
- •Standard vendor-to-vendor flows everyone runs (Stripe to QuickBooks, Shopify to Klaviyo)
- •Limited customization needs — the vendor's defaults are 80% right
- •You trust both vendors to maintain the connector long-term
- •Low-volume, low-stakes data movement
No-code wins
- •Ad-hoc workflows that business users invent and abandon monthly
- •Marketing automation handled by the marketing team without filing tickets
- •Internal one-offs between SaaS tools you might not use a year from now
- •Bridging two systems for a 90-day pilot
- •Team has no engineering capacity for the next year
iPaaS wins
- •Enterprise environment with 50+ integrations and a dedicated integration team
- •Compliance requirements that need centralized governance
- •Multiple business units sharing infrastructure
- •Budget can absorb $50K-$200K+ annual platform minimums
Custom code wins when…
The integration is load-bearing, the logic has real complexity, volume is above no-code's pricing knee, and you have engineering capacity. Custom code wins more often than mid-market companies expect — but always at the cost of upfront engineering effort. There is no free lunch.
The signals that tell you to migrate
Most integration mistakes are not picking wrong from the start — they are staying too long with the wrong choice. Watch for these signals; each is a sign the current tool is past its useful life for that integration.
- Monthly no-code subscription crossed $200 and is climbing as volume grows
- You have three or more Code by Zapier or Sub-Zap steps in a single workflow
- The integration has failed silently at least twice in the last quarter
- Business stakeholders are asking for logic the current tool cannot express
- Debugging a failure requires more than the platform's task history view
- You are paying for an iPaaS platform but only using 20% of its capabilities
- A pre-built connector is missing field mappings you keep working around manually
The migration rule of thumb
If two or more of the signals above are true for an integration, the migration cost will be paid back within 12-18 months. Migrate proactively rather than waiting for the failure that forces it.
How to actually run the cost math
Most build-vs-buy comparisons get the cost framing wrong. They compare upfront cost against upfront cost, which makes custom code look unaffordable. The right framing is total cost of ownership over a 3-year horizon, including the costs that vendors do not advertise.
Costs to include in the comparison
- Subscription fees at expected year-3 volume (not year-1)
- Engineering or vendor cost to build / maintain / extend the integration
- Cost of failures: lost revenue per hour of downtime × expected outages × resolution time
- Vendor management overhead (procurement, renewals, security reviews per vendor)
- Switching cost when the current solution stops fitting
- Internal time to debug, document, and onboard new people to the integration
The breakpoint heuristics
- No-code beats custom under $200/month in subscription cost, generally — custom payback is too long
- Custom beats no-code above $500/month, almost always — 18-month payback period is typical
- iPaaS beats custom when you have 5+ active production integrations sharing infrastructure
- Pre-built connectors beat everything when the vendor's defaults are exactly what you need — but verify against your test data, not their demo data
The hybrid pattern (what actually works)
Mature mid-market companies end up running all four categories simultaneously. The intentional hybrid pattern looks like this:
Pre-built connectors for standard flows
Stripe → accounting, Shopify → email marketing, Slack → ticketing. The vendor has thought through the integration; you do not need to. Enable, configure, move on.
No-code for ad-hoc and marketing
Marketing automation, internal one-offs, pilot integrations. Owned by business users who can iterate without engineering tickets. Accept that some of these will fail silently — keep them away from load-bearing data.
Custom code for the integrations that matter
Anything in the revenue path, the data warehouse, the financial system, or anything regulated. These are where observability, reliability, and ownership matter. Build once well; maintain at a few hours per month.
iPaaS only when the platform overhead pays for itself
Most mid-market companies do not need iPaaS. If you have a dedicated integration team and 20+ active integrations, the centralization and governance start paying back. If you have 5 integrations and one engineer, the platform cost dominates and custom or no-code is simpler.
What this looks like as an engagement
Most integration engagements we run follow the same shape. Discovery week: inventory existing integrations, rank by criticality, run the decision matrix on each. Scope: pick the 1-3 integrations where migrating or building anew has the clearest payback. Build: 4-8 weeks per integration depending on complexity. Handoff: documentation, monitoring, runbooks, your team owns it from there.
We do not push every integration toward custom code. The honest answer for most engagements is a mix: keep the long tail in no-code, migrate the 1-3 load-bearing flows to custom, leave the pre-built connectors alone. The framework above is the same one we apply internally — there is no proprietary methodology being concealed.
If you take one thing away
Pick the integration category for each individual integration, not for the company. The companies that run integrations well are the ones that stopped trying to find one platform that fits everything.
Download the The System Integration Decision Framework: Build, Buy, or Glue as PDF
One email gets you the formatted PDF + future guides as we publish them. No spam, unsubscribe any time.
Ready to put this into practice?
Most of our engagements start with the framework you just read. If you want help executing it, a discovery call is the fastest way to find out if we're a fit.