Why integrations are where projects die

When 80% is done, and the rest takes 80% of the time

The most common story we hear from clients who have been burnt on a development project often goes like this:

"The application itself was built on time. But then it had to be integrated against our ERP, and that is where everything stopped. We had to wait for the vendor, the documentation was wrong, it turned out the API did not support what we thought, and the project was delayed by four months."

That is not an exception. It is the rule for projects that require integrations. We have seen it many times, and learned to handle it differently.

Why integrations are so difficult

Not because the code is complex. Most integrations are structurally simple: fetch data from one system, send data to another, handle errors. The complexity lies elsewhere.

Documentation that does not match reality. The ERP vendor says the API returns a certain format. In practice it returns something slightly different, with fields that are not documented, and without fields documented as mandatory. You discover this only when you call the API.

Vendors who respond slowly. When you have a question about how their ERP handles a particular transaction, the question enters a queue at a support person who is not technical. Answers take one to three weeks, and often do not address what you asked.

Changes in the vendor's system along the way. The ERP is upgraded in monthly releases. Some of them break the API in subtle ways. You find out on the day the job is supposed to run.

Authentication that requires access you do not have. A Maskinporten connection requires a business certificate, which requires organisational approval, which requires a paper form signed by the managing director. While you wait, you cannot test the integration in production.

Rate limiting and throttling. The API allows 100 calls per minute. When you need to run a monthly batch requiring 50,000 calls, you have to spread it over eight hours. That means a new architecture, not just "write the code".

Data structured differently from what you assumed. The customer register in the ERP has one "customer" that is in reality ten subsidiaries sharing the same organisation number. You must understand the data model before you can use it.

How we handle it

We have stopped estimating integrations based on "it looks like a standard integration". Instead, we treat each integration as its own mini-project with three phases.

Phase 1: Technical review before fixed price

Before we give a fixed price on a project with integrations, we do one to two weeks of technical review of each integration. That includes:

• Reading through the entire vendor API documentation, not just what we need
• Setting up a sandbox or test environment, if available
• Making real API calls against the sandbox with real data
• Identifying what does not match the documentation
• Assessing the authentication process and how long it takes
• Checking rate limits and operational constraints
• Speaking with the vendor's technical contact, if possible

The result of this phase is a concrete integration specification, not just an assumption. We know the risk areas before the fixed price is set.

Phase 2: Building with built-in robustness

Each integration is built with the same four elements as standard:

1. Idempotency. Each message or transaction has a unique ID. If we send it twice, because the network dropped and we retried, it is only created once in the target system. This eliminates most "duplicate row" errors we have seen in traditional integrations.

2. Retry with exponential backoff. When a call fails because the system is down, we automatically retry after 1 second, 2 seconds, 4 seconds, 8 seconds, up to a maximum. When the system is back, we continue where we left off. No lost messages, no human intervention.

3. Queue system. All integration messages go through a queue (typically Convex scheduler, or a dedicated message queue). If one side is slow or down, the queue builds up, not the production process generating the messages.

4. Audit log on everything. Every single integration call is logged: when it was sent, what was sent, what was responded, how long it took. We can reconstruct exactly what happened 12 months ago if the client asks.

These four are not extra cost. They are the standard package. The difference is that we do not need to fix "lost messages" as an incident later.

Phase 3: Monitoring in production

We set up alerts on:

• Queues growing unusually fast (a sign that something has stopped)
• Error rate suddenly rising (a sign that the API has changed)
• Latency suddenly increasing (a sign of problems at the vendor's end)
• Missing messages from a third-party system that normally sends every hour

This means we discover problems before the client does. We often call them before they have noticed, and explain what is happening.

The most demanding integrations

Different categories of system have different pitfalls. Here are the main patterns we work with:

ERP and accounting systems. The established ones generally have good documentation and working APIs. Some have several API versions simultaneously, so choosing the right one is important, and the authentication flow varies in complexity.

CRM systems. Mostly well-documented and stable. Several require more configuration work at the client's end than initially expected.

BankID and ID-porten. Stable, but the authentication flow requires preparation. Test thoroughly in the test environment before production.

Altinn and Maskinporten. Mature services with clear documentation, but the process of obtaining a business certificate and scope approval takes time. We start that in parallel with development.

Systems in the healthcare sector. Often complex. Usually requires direct dialogue with the vendor, not just API calls. Standardisation varies between systems, so we reserve good time.

Legacy municipal systems. The most demanding category. Often old SOAP, often with authentication based on IP whitelisting, and documentation scattered across old Word files. We do not commit to a fixed price without a paid technical review first.

What you can do yourself before the project starts

If you are considering a project with integrations, do these three things before development begins:

1. Verify that you have access to test environments. Many integration projects are delayed by weeks because sandbox access is not in place. Request it now.

2. Obtain up-to-date API documentation. Not what you found on the vendor's website, but what they give to actual integration partners. It often contains fields and requirements that are not publicly documented.

3. Identify a technical contact at the vendor. Not the support ticket route, but a real person you can call when something is unclear. That shortens debugging from weeks to hours.

These three things take one to two weeks if you start now, and often save weeks or months later.

Our approach

We have learned this the hard way across many projects: integrations are not where you should save time or money. They are where you should invest extra in preparation and robustness. The payoff is systems that work in production, not just in the test environment.

When you speak with a potential development partner, ask directly: how do you handle integration projects? If the answer is "we follow best practices", that is vague. If the answer is "we do a technical review before fixed price, build with idempotency and retry, and set up monitoring from the start", you have someone who has done this before.

Talk to us about the integration project you are considering, or read about our approach to integrations and systems development.