When does your business really need API integration?

Some companies pay tens of millions for integration they did not need. Others lose far more every month by postponing it.

The difference is not company size. The difference is whether anyone has calculated it in numbers.

This article will make you calculate it yourself. If the answer is that you do not need it, we will say so — that serves us better in the long run.

Test yourself: seven questions, two minutes

Answer honestly. Count how many you answer "yes".

• Someone copies data from one application to another every day.
• Two systems hold the same data, and the figures often differ.
• Monthly reports must be assembled by hand because the data is scattered.
• A customer has waited, or been disappointed, because stock was only updated the next morning.
• Orders from the online store must be retyped into the point-of-sale system.
• Work has to be done outside working hours only because the systems are not connected.
• You have paid overtime for work a machine could have done.

The result: zero to one "yes" — not needed yet, and you should not start. Two to three — start planning one flow only. Four or more — you are already paying the cost every month without realising it.

Calculate the loss, do not estimate it

The figures below are often surprising, yet the arithmetic is simple. Take one person whose job involves copying data, then work out:

• How many hours a day go into copying rather than analysing?
• What does one hour of their work cost, including salary, allowances, and overtime?
• Multiply hours by cost, multiply by 22 days, multiply by 12 months.

Example: two hours a day, labour cost four million a month. Two hours out of an eight-hour day is a quarter of their time. A quarter of four million is one million a month — twelve million a year. Every year. Without end.

That does not yet include the errors that come from boredom and fatigue: wrong stock, swapped orders, customers who do not return. That kind of loss never appears as a line in the accounts, because nobody records it.

If your figure is above thirty million a year, integrating one flow usually makes sense arithmetically — even before counting the time that could go into more useful work.

When you should not start at all

We turn down integration work more often than we accept it. Four situations make the work almost certain to waste budget:

• There is no internal agreement on which data is authoritative. Connecting two systems that each believe they are right only spreads the disagreement faster.
• One of the systems will be replaced within six months. You would be paying twice.
• Volume is small and frequency is rare. If copying still happens once a month and has never been wrong, it is cheaper than integrating.
• Nobody on your team can grant access to the systems. Work will stop waiting for permission, not for code — and that is what stretches projects most often.

Why integration often fails

Not because the code is hard. Almost always because the order of work is wrong.

The most common mistake: connecting everything at once. Six systems, three months, one large budget. When one system turns out to store data in a format nobody ever documented, the whole project stalls.

The approach that works is the opposite, and sounds less impressive when proposed: take the single most painful flow, finish it until it is genuinely in use, measure whether time actually dropped, then move to the next flow.

The first piece usually takes two to four weeks, not months. If a vendor proposes a six-month integration as the first step, ask what can be delivered in the first three weeks — and whether that result can be used without waiting for everything to finish.

What separates a reliable vendor

Integration is not a one-off job. Systems change, APIs are updated, data grows. What matters is not only whether the integration works today, but whether it still works six months from now.

• A good vendor asks which data is authoritative before writing code, not after.
• They give you a data flow diagram you can show to other teams — not only code nobody but its author can read.
• They give a time estimate for each flow, not one large number for everything.
• They name what cannot be done, and what would stop the project.
• And the easiest to check: they are willing to say which parts you do not need to pay for.

The next step, without deciding anything

If your test came out at four "yes" or more, send us these four things. We will reply with an honest assessment — including if the conclusion is that you do not need integration yet.

• Which applications you want connected, by name.
• The one flow that bothers you most right now.
• Who can grant access to each application.
• How often data needs to move: instantly, hourly, or daily is enough.

Those four things are usually enough to give an approach, a time estimate, and a cost range — at no charge and with no obligation.

We give a cost range first, not after you have signed something. If our figure does not work for you, you still gain something useful: clarity about what your business actually needs.