Integrations eat more time than the product itself

When you sit down to plan a new project, what usually lives in your head is the "product": the screens, the logic, the features people will use. It feels like that's the work. Then time passes and you notice that most of it was eaten not by the product, but by integrations — connecting to other people's systems that you didn't write and don't control.

The more serious the project, the more obvious this gets. Payment systems, banks, an operator's billing, telephony, CRM, maps, government services, the warehouse, couriers — almost nothing interesting lives in a vacuum. A real product almost always stands on a dozen external APIs.

Why it's so expensive

You understand your own code completely. Someone else's system — you don't. And it's exactly at that boundary that the most time-consuming things hide.

• The docs lie. Not maliciously — they just lag behind reality. A field marked required arrives empty. A response described as JSON sometimes comes back as an error string. Until you've seen real traffic, you don't know how it behaves.
• Formats and small things. Encodings, time zones, date formats, money (minor units vs decimals, rounding). One wrong cent in a payment is no longer a "small thing."
• The network isn't perfect. The request went out, the response was lost — but the money was charged. So you need timeouts, retries, idempotency, deduplication, queues. Half the work on an integration is handling what went wrong.
• Two systems, two truths. Your database says one thing, theirs says another. Now you have reconciliation, compensating operations, manual investigation of mismatches.
• Access and security. Request signing, tokens, key rotation, "send us a static IP," allowlists, a separate channel. That's time too.
• Test environments are missing or don't match production. And you learn how the system behaves on live traffic.

On top of all this — the organizational part. On the other side of the API there's another team with its own releases, its own schedule and support through tickets. Sometimes the answer to "why does it work this way" arrives a week later.

From experience

I've built integrations with CRM and telecom systems, USSD and SMS services, banks and merchant infrastructure, and — in my own delivery business — with telephony. The tasks differ, but the bottleneck is always the same: not "writing my own logic," but reliably getting along with someone else's system that lives by its own rules and sometimes quietly changes behavior.

That's why the estimate "the product itself — one week" almost always turns out incomplete. The product, yes, one week. Then three weeks making it talk correctly to everything it's connected to.

What helps

Over the years I've picked up a few habits that genuinely save nerves:

• Hide the foreign side behind an adapter. A separate layer that translates someone else's API into your model. When their side changes, you fix one layer, not the whole product.
• Assume everything will fail. Timeouts, retries with backoff, idempotency keys, queues. Not "if" but "when."
• Log the actual exchange. When something diverges, the argument is settled not by documentation but by the request/response log. Observability matters more than it seems.
• Document actual behavior, not the promised one. Your own notes on someone else's API are often more useful than their official docs.
• Budget time for integrations up front. Not at the end "just in case," but as the main part of the work.

The main point

Over time I stopped seeing integrations as "gluing" a finished product to the outside world. More often than not the integrations are the product — or at least its largest and hardest part. The user never sees this layer, but it's what decides whether the system actually works or only works in a demo.

So when I plan a project now, I ask myself the uncomfortable question right away: not "what will we build?" but "what will it have to get along with — and what does that really cost?"