Every integration quote we have ever seen go wrong went wrong in the same place: not in the build, in the assumptions underneath it. The connection itself is usually the easy part. What decides the price is a set of questions that are cheap to ask up front and expensive to discover in week six.
These are the ones we ask before we put a number on an integration. If you are buying one - from us or from anyone - they are worth asking your supplier too. A vendor who cannot answer them is not quoting your project, they are quoting a project.
1. Who owns the interface on the other side?
Not which system. Which person. Integrations connect two organisations as much as two applications, and the second one has its own release calendar, its own change process and its own opinion about whether this is a priority.
The question behind the question is: when we need the other side to change something - add a field, widen a rate limit, fix a certificate - how long does that take and who decides? On a project where the answer is "our own team, next sprint", the risk is small. Where the answer is a third-party vendor with a support contract and a four-week SLA, that turnaround is on the critical path and belongs in the estimate rather than in the apology.
2. What does the contract say, and is it true?
A WSDL, an OpenAPI file, a PDF from 2019, or nothing. Each of those is a different amount of work.
The trap is the second one. A generated WSDL is usually right because it is generated. An OpenAPI file is frequently written by hand after the API was built, and it drifts. We have lost more days to a documented field that does not exist than to any API that came with no documentation at all - because when there is no contract, you test everything, and when there is a wrong one, you trust it until something breaks in UAT.
Budget a spike to call the real endpoint with real credentials before the estimate is fixed, not after.
3. How much data, and how bursty?
Volume matters less than shape. Ten thousand records a day spread evenly is a different system from ten thousand records arriving in four minutes at month end, and only one of them needs queueing, back-pressure and a retry strategy.
Ask for the peak, not the average, and ask when it happens. Then ask what the other side's rate limit is. Those two numbers together tell you whether this is a straightforward call-and-respond integration or a piece of infrastructure.
4. What happens when it fails halfway?
This is the question that separates estimates that hold from estimates that do not.
The network drops mid-call. The receiving system accepted the record but the acknowledgement never arrived. You retry. Does the other side create a second order, a second ticket, a second payment - or does it recognise the retry and return the original result?
If it deduplicates, you are fine. If it does not, someone has to build idempotency: a key on every request, a store of what has already been processed, and a decision about how long to remember. That is real work, it is invisible in a demo, and skipping it is the most common integration defect we are called in to fix. It is also the one that costs the most to retrofit, because by then there is bad data to clean up as well as code to write.
5. Who is watching it on a Tuesday?
An integration is not delivered when it works. It is delivered when someone finds out within minutes that it stopped working, and knows what to do.
That means deciding, before the build: where do failures go, who reads that, what does a retryable error look like versus one that needs a human, and how does an operator replay a batch that failed overnight? Teams that leave this to the end ship an integration where every failure looks identical to the service desk, which is functionally the same as having no monitoring at all.
6. What does "done" mean?
For a fixed price to be fixed, the boundary has to be. Which fields, which direction, which error cases, whose test environment, and what specifically has to pass for the work to be accepted.
We would rather spend two hours arguing about that list than deliver something that meets the brief and disappoints the buyer. A scope that fits on one page and is genuinely agreed is worth more to both sides than a generous-sounding one that leaves the hard cases undefined.
Why we quote this way
We sell fixed-time, fixed-price delivery, which only works if the estimate is honest. The way to make it honest is not padding - it is asking the six questions above before committing, and being willing to say that one of them needs a paid discovery week before anyone can name a number responsibly.
Where the answers are clear, a fixed price is straightforward and you carry no risk. Where they are not, we would rather tell you that than find out together in week six.
If you have an integration to scope - ServiceNow, BMC Remedy, IBM Maximo, or something connecting to them - tell us what the two ends are and we will tell you which of these six is going to decide the price.