Seven Questions to Ask Any Integration Partner Before You Sign

Most integration projects do not fail during the build.

These are the questions that distinguish a true integration partner, one who will remain valuable well into year two and beyond, from those who won’t. If our own answers don’t stand up to these questions, we don’t deserve the work..

1. What happens when the source API changes its schema?

Ask this first, because it is the one that predicts the next two years.

Every platform you connect to will change something eventually. Fields get renamed, endpoints get versioned, a payload that was a string becomes an object. Whether that breaks your business quietly or gets caught before anybody notices comes down entirely to whether the provider built change detection or just built the connection.

A good answer describes a mechanism. Something that watches the shape of incoming data and alerts when it drifts, or a contract test that runs against the live API on a schedule. A weak answer is “we monitor it” with nothing behind that, or “we’ll fix it when it breaks.”

We learned this one the expensive way, so here is our own uncomfortable story. A logistics client had an AI step in their funnel, and a model update quietly changed how it returned its data. The integration had been built without strict validation and without a retry loop, so when the response shape drifted, nothing refused it. Worse, it did not fail every time. It worked five or six times in a row, then an ampersand or an apostrophe or one of the long dashes AI loves would land in a field, and the run would break and swallow the error silently. The client noticed before we did. That is the part a case study never includes, and it is why the question matters: the fix was strict validation, graceful re-requests, and tooling we built afterwards specifically to hammer integrations with cursed input until the fraying edges show. Ask your provider what their equivalent of that lesson was. If they have never had one, they have not run enough integrations in production.

2. Who owns the code when we are finished?

You should. Ask directly, and get the answer in writing before anything starts.

Some providers build your integration inside their own platform, which you then rent indefinitely. That can be a reasonable trade if you know you are making it, because you get maintenance included and someone else’s problem to solve. It stops being reasonable when nobody told you, and you discover it two years later while trying to switch.

The follow-up question is better than the first one: if we parted ways tomorrow, what would we still have? A repository we can hand to another developer is a very different answer from a login. We have seen what the ugly version of this looks like in a contested code handover, and the buyers who came out of it intact were the ones who could name exactly what they were owed.

3. What does this cost to run, not just to build?

Build cost is the number everybody quotes. Run cost is the number that decides whether the project was worth it.

Ask for the hosting, the API call volumes, the licence tiers your data volume will push you into, and what happens to all three if your transaction count doubles. The uncomfortable version of the question is what the bill looks like in month thirteen, once the volume has grown and the introductory tier is a memory. A provider who has done this before will have the numbers close to hand. One who has not will treat the question as premature.

4. Can you show me something you built that broke, and what you did?

Anybody can show you a case study where everything worked.

What you are testing here is whether they will tell you the truth when something goes wrong, because something inevitably will. The useful answer is specific and slightly uncomfortable: here is what we missed, here is how we found out, here is what changed afterwards. An answer that nothing has ever gone wrong is either untrue or means they have not done enough work yet.

5. Who actually does the work?

Ask who writes the code and where they are, and whether the people in this meeting are the people on the project.

There is nothing wrong with a team, and nothing wrong with subcontracting when it is disclosed. The pattern to watch for is the senior engineer who is impressive in the sales meeting and never seen again once the contract is signed. Ask to meet whoever will be doing the building.

6. What will you refuse to do?

This one catches people out, and the answer tells you more than the sales deck.

A provider with real judgement has things they will not build, because they have seen those things fail. Direct database writes into a platform that has a perfectly good API. A sync with no reconciliation step. A dashboard fed by a nightly export that the client will treat as real time. If somebody will build anything you ask for without pushback, you are not buying expertise, you are buying hands.

Here are things we have said no to. A rubbish removal business wanted AI to quote by estimating the weight of a pile from a photo. Size, yes. Weight, no. Two fridges the same size can differ by forty kilos of compressor, and a quote built on a guess is a dispute waiting for a truck. We have also turned down chatbot projects, including for a telco, because a bot that can only search the FAQ is a worse experience than the FAQ, and we will not put our name on one. Sales funnels get a flat refusal: when an interested buyer calls, a person answers. That call is the most valuable moment in the pipeline, and automating it optimises away the sale.

The pattern behind every refusal is the same. People ask AI for information that does not exist anywhere it can reach, and AI will answer anyway and do so confidently, because that is what it does. The dumbest and most dangerous outputs come from putting a model in a vacuum and demanding certainty. A good partner knows where the vacuum is and tells you before you pay to find out.

7. What does handover look like?

The project ends. What do you have?

At minimum: a repository you own, documentation a new developer could work from, credentials in your own accounts rather than the provider’s, and a clear statement of what runs where. Ask what the first week without them looks like. If that question produces a vague answer, the dependency is the product.

What good answers have in common

None of the seven are technical questions, which surprises people.

They are all about what happens after the invoice is paid, because that is where integration projects live or die. Providers who have maintained their own work for years answer these easily and specifically, usually with a story attached. Providers who build and move on find them awkward, and the awkwardness is the signal.

Use them on us too. We connect business platforms and build CRM integrations for clients across Australia, and every one of those seven has an answer we are happy to give in a first call. If you would like to test that, get in touch or call 1300 840 340. If you would rather see the work first, the case studies are there.