# How to evaluate integration before buying a tool

> Before signing with a new software vendor, check the API, data export and cost of leaving. A six-point routine so you don't buy yourself an island.

- Author: Marlon Trettin
- Published: 2026-08-13 · Updated: 2026-08-29
- Language: en
- Canonical: https://yowpi.com/en/blog/evaluate-integration-before-buying-a-tool

---

Evaluating integration before buying a tool means answering six questions: whether the API is documented, whether there are webhooks, whether your data comes out complete, whether the data model is open, what it costs to connect and what it costs to leave. Skip that step and you buy an island. Islands are expensive to run.

## TL;DR

- The average company manages 957 applications and only 27% of them are connected, according to [MuleSoft's Connectivity Benchmark 2026](https://blogs.mulesoft.com/agentic-perspectives/connectivity-benchmark-report/).
- In the same study, 82% of IT leaders name data integration as the biggest obstacle to using AI, and technical teams spend 36% of their time building integrations on demand.
- Business units now control 81% of SaaS spend while IT directly manages 15%, according to [Zylo](https://zylo.com/news/2026-saas-management-index). The tool arrives through a corporate card, not through an architecture review.
- Six checks made before signing cut the risk of months of rework after go-live. The routine is below.

## Why does integration fall outside the buying decision?

Because the purchase happens far from whoever has to integrate. Business units already control 81% of SaaS spend, and IT directly manages only 15%, according to the [SaaS Management Index 2026 from Zylo](https://zylo.com/news/2026-saas-management-index). The tool comes in on a corporate card, through a manager's urgency, or off the back of a good demo. The question of how it talks to everything else turns up after the contract.

The demo carries part of the blame. Vendors show screens and reports, because that is what sells. Nobody opens API documentation in a sales meeting. But the real cost of the tool is not in the monthly fee: it is in what the tool demands from your operation in order to work connected to what you already run.

The result shows up in the numbers. Over the last 12 months, [78% of IT leaders reported unexpected charges](https://zylo.com/news/2026-saas-management-index) tied to consumption-based or AI-based pricing, and 61% cut projects because of unplanned increases in SaaS cost. The surprise invoice and the unevaluated integration come from the same hurry.

## What do you check before signing?

Six points, in order of elimination. Fail one of the first three and the conversation with the vendor changes tone.

First, the API. It is not enough for the vendor to say there is one. Ask for the public documentation and check whether the data that matters to your operation — customer, order, status — can be read and written through it. An API that only allows reading is half an API.

Second, webhooks or events. Without them, your other systems have to keep asking whether anything changed, and information moves in batches. With a webhook, the tool tells you at the moment the thing happens. For any flow that depends on a fast reaction, that difference decides the whole design.

Third, the export. Ask for a full test export and open the file. Check whether every field comes out, history and attachments included, or only a summary. Data that does not come out whole is data that, in practice, belongs to the vendor.

Fourth, the data model. Ask whether the tool accepts an external identifier for customers and records, the same one your other systems use. When it does not, your operation starts maintaining lookup tables between codes forever, and every cross-system report becomes a small project.

Fifth, the cost of connecting, in the budget. Integration has a price: developer hours, a paid connector, or the higher plan that unlocks the API. That number belongs in the business case for the purchase, not in next quarter's surprise. IT teams already spend [36% of their time](https://blogs.mulesoft.com/agentic-perspectives/connectivity-benchmark-report/) designing, building and testing integrations between systems, according to MuleSoft.

Sixth, the exit. Before you go in, know how you get out: how long the data stays available after cancellation, what format the final export arrives in, and what migration costs. A good exit clause is one you read carefully and hope never to use.

## Who asks these questions inside the company?

Whoever approves the tool. In practice, the innovation manager is the filter between a department's enthusiasm and a signed contract. You do not need to be technical to run the routine: the six answers come from the vendor, in writing, and IT or a technical partner validates what came back.

There is one test that stands in for all six points. Ask for a sandbox and move a real record there and back: a customer created in the new tool showing up in your current system, and the reverse. If the vendor cannot put that proof together in a week, you already have the answer you needed.

The bar is not perfect connection on day one. It is knowing, before signing, how big a bridge your team is going to build. The thesis that guides our work applies here too: you do not have a technology problem, you have an architecture problem. A new tool with no defined place in the architecture is one more island on the map.

## How does this work in practice?

A hypothetical scenario, assembled from situations we see often. A mid-sized distributor decides to buy delivery management software. The demo convinces, the price fits the budget, the contract is signed in two weeks. Six months later, the innovation manager discovers that the only way to get delivery data into the ERP is a manual CSV export, every day, done by someone on the team.

The bill for that discovery: one person spends an hour a day retyping, the delivery metric runs 24 hours behind, and finance closes the month with figures that do not match. The uncomfortable detail is that a single question about the API before signing would have prevented all of it.

The opposite path exists too. In projects like [UniTrust](/en/cases/unitrust), the brokerage that has been scaling policy and commission management since 2022, and [Reatop](/en/cases/reatop), which structured environmental management into an ecosystem connected to a mobile app, integration was designed before the tools rather than patched on afterwards. The cost difference between the two paths is the difference between a project and permanent rework.

## Frequently asked questions

**I can't justify this evaluation process right now. Is it worth the effort?**

The six-point evaluation costs a few hours and one meeting with the vendor. An integration discovered after the contract costs months and, often, a whole project: [61% of IT leaders cut projects](https://zylo.com/news/2026-saas-management-index) because of unplanned SaaS cost increases. The cheap effort is the one before signing.

**Doesn't implementing a well-integrated tool take too much of the team's time?**

Implementation time exists in both scenarios. The difference is where it shows up: planned into the adoption schedule, or disguised as permanent retyping in the team's daily routine. Integration evaluated up front becomes a task with a beginning and an end. An island discovered later becomes a fixed cost.

**How do I measure the result of demanding integration at purchase?**

With three simple indicators: weekly hours of manual retyping and exporting between systems, time between an event and the data being available in a report, and the number of discrepancies between systems at month-end close. Measure before the tool arrives and three months after. If the indicators did not fall, the integration stayed on paper.

## The criterion that protects the others

Features get compared in a table and price gets negotiated. Integration is the criterion that decides how much of the tool your operation will actually use, and it is the only one of the three that almost never enters the decision. Putting the six points into your buying process costs little and changes the outcome of every project that comes after.

If you want an outside look at how your operation's tools connect, or should connect, the [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation to map exactly that.