What an integration actually costs, broken down

Someone has asked you to approve an integration and the number in front of you has no shape to it. It might be two days of work, it might be six weeks, and nothing in the request explains the gap. The cause is almost always the same. Whoever estimated counted the happy path, the single successful call that moves a record from one system into another, and stopped there. That part genuinely is fast. Everything wrapped around it is the actual project: auth that expires, paging that lies about totals, a backfill of ten years of history, and the retry logic for the afternoon the target returns 503 for twenty minutes. Here is where the hours really go, in engineering-days rather than currency, because rates vary too much to be useful.

The happy path is about a quarter of the job

Write the client, authenticate once by hand, pull ten records, map the fields, push them into the destination. Against a documented REST API with a working sandbox, that is an afternoon of work, and it is the version everyone sees in the demo. The trouble is that the demo runs on ten clean, recent records that you picked. Production hands you ten years of accumulated state: records created before a required field existed, currency codes that were free text until 2019, a customer whose name contains the delimiter you chose, deleted rows that still hold foreign keys. Across the integrations we build, the working call is roughly a quarter of the total effort. The rest goes on everything that happens when the input is not what you tested against, and on proving that it holds up.

A useful way to sanity check an estimate is to ask what share of it covers failure. If the breakdown is all mapping and no retries, no reconciliation, no alerting, it is describing a prototype. Prototypes are legitimate and sometimes exactly what you want. They are just not the thing you can leave running unattended over a long weekend. The distinction matters because the two are priced an order of magnitude apart, and the word "integration" covers both. We went through that gap in more detail in moving a pilot into production, and the same arithmetic applies whether or not there is a model in the pipeline.

Where the days actually go

1. 1 Discovery and API archaeology
   Read the docs, then find out where they are wrong. Get credentials, confirm which API version the system is actually on, and probe the endpoints you need for fields nobody documented. Budget 1-3 days, more if no one internally knows how the source system was configured.
2. 2 Auth and credential handling
   An API key in an environment variable is half a day. OAuth with refresh tokens, token storage and a rotation path is closer to 2-3 days once you account for the refresh race between concurrent workers. Certificate or mTLS auth against an on-prem system adds another day or two of network and trust-store work.
3. 3 Core data mapping
   The field-by-field translation, plus the decisions nobody wrote down: what to do when a required destination field has no source, how to resolve identity between the two systems, which side wins on conflict. Typically 2-5 days, and it grows with the number of entity types rather than the number of fields.
4. 4 Pagination, backfill and incremental sync
   Paging through a live, changing collection without dropping or duplicating rows is its own problem. Then the initial backfill has to run at a rate the target tolerates, resume after a failure, and be safe to re-run. Call it 2-4 days, longer if the history is large or there is no reliable modified-since filter.
5. 5 Error handling, retries and idempotency
   The single largest line item, usually 3-6 days. Classify which failures are retryable, add backoff, make every write safe to repeat, and build a dead letter path so one poison record does not stall the queue. Our notes on idempotent integrations cover the patterns worth stealing.

Four more lines belong in every estimate and are the ones most often left out. Observability, 1-2 days: structured logs, a record-level trace you can search when someone asks why an order is missing, and an alert that fires on a stalled sync rather than only on a crash. Testing against real payloads, 2-4 days: a fixture set captured from production, plus the malformed and boundary cases you will only find by looking. Deployment, 1-2 days: scheduling, secret management, environment promotion, and a rollback that does not depend on a human remembering the steps. Documentation and handover, 1 day: a runbook that tells whoever is on call how to replay a failed batch at 2am without paging you.

What makes a target system expensive

Two systems with near-identical feature lists can differ by a factor of three in build cost, and the reasons are structural. No sandbox is the biggest one: if the only environment is production, every test becomes a negotiation, you cannot generate the error conditions you are supposed to handle, and the write path has to be validated with a handful of real records and a lot of care. Add days for that. SOAP, or a bespoke XML dialect over HTTP, is the second: modern tooling handles it badly, the WSDL is often stale, and you end up hand-building envelopes and parsing responses that nest three levels deeper than they need to. Neither is a reason to walk away. Both are a reason to double the discovery line before you commit to anything.

The rest of the expensive list. Per-tenant custom fields, which make your mapping data rather than code, so now it needs a configuration model and either a UI or a schema someone can edit safely. Aggressive rate limits, which turn a two-hour backfill into a three-day one and force you to build queueing and resumption you would otherwise skip. No webhooks, so you poll: choose an interval, detect changes yourself, handle the window where a record changed twice between polls, and pay for the compute to run it forever. And undocumented behaviour, the category that cannot be estimated in advance: a field that accepts 255 characters but silently truncates at 200, a status that transitions on its own overnight, an endpoint that returns 200 with the error hidden in the body. You find those in week three. Legacy ERP is where all five tend to arrive together, which is why connecting agents to an ERP is rarely the two-day job it looks like.

One connection or one thousand

A single connection to one system your company controls is the cheap case. You know the credentials, the configuration, the data, and the person who can answer a question. Multi-tenant is a different project wearing the same name. Credentials now have to be stored per tenant, encrypted, rotated and revoked. Every tenant has slightly different custom fields, so the mapping becomes configurable. Rate limits apply per tenant, so the scheduler has to be fair rather than greedy. Errors have to be attributed and surfaced to the right customer without leaking anything about the others. Onboarding needs a self-serve path, or you own it manually forever. As a planning number, budget 2-3x the single-connection estimate for the first multi-tenant version, and expect support cost to keep scaling with tenant count rather than flattening out.

The two-day integration is real

Not every integration is a project, and it is worth being precise about which ones are not. One direction, into a single system you control, over a documented REST API with an API key and a sandbox, moving one entity type with fewer than twenty fields, at a volume where a single page of results covers a run, with no backfill and manual re-runs on failure. That is two days, honestly, sometimes one. Posting new form submissions into a CRM. Mirroring a status change into a chat channel. Dropping a nightly export into object storage. The tell is that failure is cheap: if the job does not run tonight, someone notices tomorrow and clicks a button. The moment failure becomes expensive or invisible, you are buying the full list above, and the honest number moves by a factor of ten.

Maintenance is a monthly line, not a one-off

Integrations decay because the systems on both ends keep changing and neither one tells you. An API version gets deprecated with a six-month notice nobody read. A field that was optional becomes required. A partner rotates a credential. Volume triples and the rate limit you were comfortably under becomes the bottleneck. In our own experience a live integration takes something like half a day to two days per month of real attention, averaged across a year, and it is lumpy: nothing for four months, then three days in one week when a vendor ships a breaking change. Budget it as a standing line rather than as an incident, because the alternative is that it quietly gets paid for out of someone's evening. If you are weighing a build against a managed connector, that maintenance line is usually the deciding number, which is the case we set out in build or buy.

How to read an estimate

When a number arrives, ask four questions. What does it assume about the target system: is there a sandbox, are there webhooks, what is the rate limit? What happens on failure: is there a retry policy, a dead letter path, an alert that reaches a human? What is included after go-live: who watches it, who fixes it, and out of whose budget? And what would make this cheaper: dropping the backfill, accepting a longer sync interval, handling one entity type instead of four? That last question is the most useful, because scope is the only variable you genuinely control. Rates differ and teams differ, but a five-day integration and a twenty-five-day integration are almost never the same integration described by two people. They are two different scopes, and the conversation is really about which one you need.