How to Choose a Software Integration Company

Search for a software integration company and you get directories. Top 15. Top 25. Top 26. Top 30. Ranked lists of firms, sorted by criteria nobody explains, published by sites that make money on the referral.

None of them tell you the thing that actually determines whether your project works, which is not the vendor’s tech stack, headcount or client logos. It’s whether they can understand your business well enough to encode it.

We know how badly that can go, because one of our clients went through ten firms before it went right.

The ten-firm problem

Pablo Turletti spent more than fifteen years building a causation-based methodology for measuring marketing ROI — connecting marketing activity to actual business and financial outcomes rather than to clicks and impressions. He wrote three books on it. He founded the ROI Marketing Institute. He is a Forbes contributor. The methodology worked; it just lived in his head, his spreadsheets and his judgement, and it only scaled as far as his own calendar.

He evaluated roughly ten development firms and AI consultancies to turn it into software. He hired several of them. None could grasp the underlying business logic well enough to build a working platform architecture.

That is a striking failure rate, and it is worth being precise about what failed. These were not incompetent engineers. They could all build software. What they could not do was hold the domain logic in their heads long enough to design a system around it — so they built what they understood, which was a reporting tool, when the requirement was a reasoning engine.

The resulting build with Cogya cut attribution analysis from four days to seconds at roughly 50% higher accuracy than correlation-based approaches, with users reporting 30%+ marketing budget savings during pilot use. (Full case study)

The gap between attempt ten and attempt eleven was not technical capability. It was comprehension.

What “integration” actually has to mean

Before you evaluate anyone, be precise about which of three jobs you’re buying, because firms that are excellent at one are often bad at another.

Connecting systems. Moving data between tools that already exist — a CRM to an accounting package, a supplier portal to an inventory system. Well-understood work with well-understood pricing.

Reconciling meaning. Making two systems agree on what a record is when they disagree. This is where most integration projects actually fail, and it is a business-logic problem wearing a technical costume.

Encoding judgement. Taking a decision a person currently makes — which supplier fits this requirement, is this exception a damage claim — and building a system that makes it reliably.

Most directory listings treat all three as one category. They are not. A firm that has only ever done the first will quote confidently on the third and discover the problem in month two, at your expense.

We’ve written separately about where the line falls between automating a task, integrating systems, and building a system outright — worth reading before you brief anyone, because getting that classification wrong is the most expensive mistake available at this stage.

Seven questions that separate the firms

These are ordered by how much they reveal. The first three are the ones that matter.

1. “Who on your team will sit with our domain expert, and for how many hours?”

The correct answer is a named senior person and a number measured in days, not a kickoff call and a requirements document. If the answer routes you to a business analyst who will “gather requirements” and hand them to an offshore build team, you have found attempt number four.

2. “Show me something you built where the hard part was understanding the business, not the technology.”

Ask them to explain the domain logic itself — not the architecture. If they can teach you their client’s business in five minutes, they learned it. If they describe the tech stack instead, they didn’t.

3. “What did you refuse to build, and why?”

A firm that has never talked a client out of scope has never had the standing to. This is the single best signal of whether you’re buying advice or order-taking.

4. “What happens when our requirements turn out to be wrong?”

They will be. Some part of what you specify will be a description of a workaround rather than a real requirement. You want a firm that expects this and has a checkpoint rhythm to catch it — weekly demos against working software, not a milestone plan that assumes month-one thinking survives to month six.

5. “How will we see it working before it’s finished?”

Phased delivery with demos before each phase locks. If the first thing you see is at UAT, you have no steering ability and you will pay for that.

6. “Where does a human stay in the loop, and why there?”

Any serious firm has an opinion about which decisions must keep a person in them. A firm that promises full automation of a judgement-heavy process either doesn’t understand the process or doesn’t intend to be there when it misfires.

7. “Who owns the data model?”

You should. If the schema is proprietary to the vendor, the integration is a hostage arrangement.

What to ignore

Company size. The ten firms included larger operations than the one that succeeded.

Sector-specific case studies. More precisely: don’t over-weight them. The pattern that matters — expert judgement, unstructured input, fragmented systems — transfers across industries far better than most buyers assume. A firm that has solved your shape of problem in a different industry is usually a better bet than one that has built generic software in yours. The same architecture underpins marketing attribution, procurement bid management and delivery operations.

Directory rankings. They are advertising.

Certifications and partner badges. They indicate a firm can use a platform. Your problem is upstream of the platform.

The tell that shows up in the first meeting

Describe your problem, then stop talking and see what they do with the silence.

A firm that will succeed asks a question that shows they’ve noticed the awkward part — the exception you glossed over, the reason two of your systems disagree, the thing your team works around. They’ll want to know why, and they will not be satisfied with the first answer.

A firm that will fail moves to solutions. They will describe an architecture, or a platform they’ve used before, or a phased plan. It sounds decisive and it is the opposite: it means they’ve mapped your problem onto something they already know rather than looked at it.

The second kind is more reassuring to sit with. That’s the trap.

Before you go to market

Two things are worth doing first, and they cost you nothing.

Write down the decision you want the system to make. Not the features — the decision. “Which supplier should we quote for this line item, and why.” If you can’t write it in a paragraph, no vendor will build it, and the discovery you’re about to buy is really you working out your own process at consultant rates.

Identify who has the knowledge, and check they have the hours. Every one of these projects bottlenecks on the busiest person in the company. If that person cannot commit real time, the project will fail regardless of who you hire. That is worth knowing in advance rather than in month three.

Get those two right and the vendor choice gets much easier — because you’ll be able to tell within one conversation whether they understood you.

If you want to test that, bring us the problem and see which kind of meeting it turns into.