Which Integrations to Build, and Which to Politely Decline

Integrations are a permanent commitment

A feature you build is yours to change. An integration is shared with a company that will alter its API, deprecate endpoints and change authentication on its own schedule, and your customers will experience their changes as your outage.

That is why the count matters less than the quality. A product with three integrations that always work is more credible than one with twelve, four of which are quietly broken.

Choose by evidence, not by anecdote

1. Count actual requests with the account and deal value attached, over at least a quarter.
2. Ask what breaks without it. “Nice to have” and “we cannot adopt without it” are different categories.
3. Check the API quality before promising anything. Some popular products have painful integration surfaces and the work will take three times your estimate.
4. Estimate the maintenance, not just the build. Assume attention every quarter, and more for fast-moving platforms.

The tiers worth thinking in

Two-way sync is the one that surprises people. Conflict resolution — what happens when both sides change the same record — is a design problem with no universally correct answer, and it never stops needing attention.

Do not underestimate the boring tier

A well-built CSV import with good validation and clear error messages solves a startling proportion of integration requests, in days rather than months. Many customers asking for “an integration” want their data in without typing it.

Before committing to a two-way sync, ask the requesting customer what they would do with the integration on a typical Tuesday. Frequently the answer is a weekly export, which you can ship next week.

Build the plumbing once

Before the third integration, invest in shared infrastructure: credential storage, token refresh, retry with backoff, rate-limit handling, error surfacing to the customer, and a sync log they can look at.

Teams that skip this write the same fragile code repeatedly and end up with integrations that fail in different ways, each needing its own debugging. The shared layer typically pays for itself by the fourth integration.

Tell customers when it breaks

Integrations fail. The difference between a minor annoyance and a lost customer is whether they found out from you or from missing data three weeks later.

Surface sync status in the product, alert on repeated failures, and make the error message say what to do — reconnect, check permissions, contact support — rather than reporting a status code.

Frequently asked questions