Point to point integration problems: why script sprawl breaks

The quadratic math

Point to point means every integration is a direct, custom link between two systems: a script, a function, a Zap. Each new system your company adopts can need a link to several existing ones, so the link count grows on a curve while your team grows on a line, if at all:

Systems	Possible direct links (n(n-1)/2)	Typical live links
4	6	3 to 4
6	15	6 to 8
8	28	10 to 14
10	45	15 to 20
15	105	25 to 35

Nobody wires every pair, which is why the middle column overstates it. But the right column is the honest one, and it is bad enough: a 60-person company running 10 SaaS systems typically maintains 15 to 20 live links. At 20% of an engineer's time each, the glue is quietly consuming 3 to 4 full-time engineers.

The six problems, in the order they surface

• 1. Silent failure. Scripts do not come with monitoring, so the default failure mode is nothing: no error, no alert, no data. The Shopify-to-ERP export dies on a Friday API change and is discovered the following Thursday, when a customer asks where their order went. Retries, alerting, and per-record logs are exactly the parts a deadline-driven script never gets.
• 2. Tribal knowledge. Each link embeds decisions (which field wins, how currencies convert, what happens on nulls) in code only its author understands. When that engineer leaves, the link becomes read-only infrastructure everyone is afraid to touch. Bus factor: one, times fifteen links.
• 3. Credential sprawl. Fifteen links means fifteen API keys and OAuth apps scattered across cron boxes, CI secrets, and someone's laptop. Rotating a key means finding every copy; the security review before your next enterprise deal means explaining why you cannot.
• 4. No idempotency. Hand-rolled links rarely dedupe. A retried run double-posts invoices; a crashed run half-applies a batch. Cleanup lands on finance and ops, whose trust in the data erodes first.
• 5. Duplicated, drifting logic. The same customer record is transformed three slightly different ways in three scripts. The CRM, the books, and the warehouse each hold a different revenue number, and the monthly meeting argues about whose is right.
• 6. Change amplification. When one vendor versions its API, every link touching it breaks separately, on its own schedule, each needing its own fix. One deprecation notice becomes eight tickets.

What it costs in dollars

Build cost is visible: 2 to 6 engineering weeks per integration, $17,000 to $50,000 loaded. The maintenance tail is the number that hides: at the standard 20%-of-an-engineer rule, roughly $35,000 per integration per year, forever. Ten live links is a $350,000 annual line item that appears on no budget, plus incident costs: missed invoices, stale CRM segments a campaign was sent to, inventory oversold because the count was 19 hours old.

The fix: hub-and-spoke

The structural answer has been the same since enterprise middleware: stop wiring pairs, wire each system once into a hub. Connections grow linearly (n adapters, not n(n-1)/2 scripts), transforms live in one reviewable place, credentials sit in one vault, and monitoring covers everything by default. That hub, delivered as a hosted service, is what the market calls iPaaS; we wrote a plain-language tour in what is iPaaS, and the per-link building block is covered in what is an API adapter.

The decision-maker version: you are not buying software so much as buying back the 3 to 4 engineers currently doing undifferentiated plumbing, and converting an unbounded, invisible cost into a bounded, visible one.

What good looks like afterward

The after-state is worth stating concretely, because it is what you are buying:

• One inventory. Every live integration is listed in one place, with its owner, schedule, and last successful run visible. The audit question "what talks to the CRM?" takes one screen, not one week.
• Failures announce themselves. A failed record retries with backoff and pages a channel if it keeps failing. Mean time to discovery drops from days to minutes, which is most of the incident cost.
• Changes are diffs. A field mapping change is versioned and reviewable, so "why do March deals have no region" is answered by a change log, not archaeology.
• Credentials live in one vault. Key rotation is one operation, and the enterprise security questionnaire stops being embarrassing.

When to make the switch

Three reliable triggers, whichever comes first:

• The first silent failure that costs money. If a dead script made it to a customer or an auditor, the next one is already running.
• The first departure. An engineer leaves and some link becomes untouchable. Migrate it before the second departure, not after.
• The third integration request this quarter. Demand is compounding; every new script deepens the hole you will eventually migrate out of.

On cost: flat platform pricing runs $49 to $399 a month depending on volume, which is less than one engineer-week per year at the top tier. The full breakdown is on our data integration pricing page. Migrations also need not be big-bang: teams typically move the two or three riskiest links to a data integration platform first, retire the matching scripts, and fold in the rest over a quarter. Kettleworks, one of our commerce customers, replaced 14 cron scripts with 14 adapters across two afternoons; the cron box was decommissioned the same month.