Ask a team where their last project slipped and the answer is rarely the feature work. It is the integration that behaved differently from its documentation.
Documented and actual are different numbers
Published rate limits are frequently optimistic, sandbox environments behave unlike production, and error codes appear that no page mentions. We assume all three until proven otherwise.
What we do in discovery
- Get credentials in week one, before anything is estimated.
- Write a throwaway script that performs the real call sequence against the real service.
- Record the actual latency distribution, not the average.
- Deliberately trigger the failure cases: expired token, exceeded limit, malformed input.
- Note anything the documentation got wrong. That list becomes a risk section in the scope.
Design for the worst observed behaviour
Once you know the true numbers, the architecture follows: a queue with backoff for anything slow, idempotency keys for anything that charges money, and a cached local copy for anything a user waits on.
Estimate integrations from measurements, not from documentation. The documentation was written by someone who was not being paid to hit the limit.
The honest estimate
An integration whose real behaviour we have observed is a line item with a number. One we have only read about is a range with a note. Clients accept ranges when they understand what would collapse them.