An integration sounds simple. System A has the data, system B needs it, and an API sits in between. On a whiteboard it is one arrow.
In practice that arrow is where most of the work hides. This article is about what an integration actually costs you, why estimates for this kind of work so often go wrong, and what you can do before a project starts to make the number more reliable.
What you are paying for
When we build an integration, the call to the API is the smallest part. The cost sits in everything around it:
- Data mapping. Your customer record in one system rarely matches the other. Fields have different names, formats and rules. Someone has to decide what each field means and what happens when it does not fit.
- Authentication. Keys, tokens and permissions need to be set up, stored safely and renewed without breaking anything.
- Error handling. Networks fail. Services go down. Requests get rejected. A good integration knows what to retry, what to queue and what to flag to a person.
- Limits and timing. Many APIs cap how often you can call them. Moving a large backlog of records is a different job from syncing one change at a time.
- Monitoring. You need to know when the connection stops working, ideally before your customers do.
- Compliance. If the data includes personal or financial details, you may need audit logs, access controls and a clear record of who changed what. This is where integration work and compliance software meet.
None of these show up in the one-arrow diagram. All of them show up in the build.
Why estimates go wrong
Most estimating trouble with integrations comes from the same place. Half the work depends on a system you do not control.
The other side is unknown
We can estimate our own code well. We cannot see inside a vendor's system. Documentation may be out of date, incomplete or missing. Behaviour that the docs describe one way can work another way in production. Until someone makes real calls against the real service, part of the estimate is a guess.
The data is messier than expected
Sample records look clean. Real records have duplicates, blank fields, old formats and values nobody remembers adding. Cleaning and reconciling that data is often the largest single item, and it is invisible until you look.
There is no test environment
Some services offer a sandbox where you can test safely. Some do not, or the sandbox behaves differently from the live system. Without one, testing takes longer and needs more care.
The scope grows at the edges
"Sync orders" becomes "sync orders, refunds, partial refunds and cancelled orders that were later restored." Each case is reasonable. Together they can change the size of the job.
The API changes later
Vendors update their APIs and retire old versions. An integration is not finished on the day it goes live. It needs looking after, and that ongoing cost belongs in the plan.
How to get an estimate you can trust
You can narrow the range a lot before any code is written.
- Name the systems and the direction of data. Which system is the source of truth for each type of record? Does data flow one way or both ways?
- Share real sample data. A small export, with sensitive details removed, tells us more than a description.
- Check API access early. Confirm you can get credentials, a sandbox if one exists, and the current documentation.
- List the edge cases you already know about. Returns, failed payments, merged accounts. Whatever your team handles by hand today.
- Decide what happens when it fails. Should the system retry quietly, alert someone, or stop? This is a business decision as much as a technical one.
- Note any compliance rules. If an auditor or regulator will ask questions about this data, say so at the start.
Picking a way to work
How much is unknown should shape how you pay for the work. We offer three ways to work, and each suits a different level of certainty.
| Way to work | Fits best when |
|---|---|
| Fixed price for a defined scope | The systems, data and edge cases are known and written down |
| A team by the month | Several integrations, or the scope will keep changing as you learn |
| A monthly block of hours with a promised response time | The integration is live and needs ongoing care as APIs change |
A fixed price only works well when the scope is truly defined. If the other system is still a mystery, forcing a fixed number usually means either a padded price or a painful change later. It is often better to settle the unknowns first, then fix the price.
See the range for your project
Our estimator gives you a price range in minutes from our current rate card. It shows build cost, monthly costs, effort by role, the timeline and every assumption behind the number. Read the assumptions closely. For an integration, they are where you will see what is known and what is not.
If you want to talk it through, Atheron Network Labs is open for projects now. Bring your list of systems and we will tell you plainly where the risk sits.
