The Software You Already Run Decides What Is Possible

A quote for an AI project has a line for the AI. On the builds I have costed it is rarely the biggest one, and often around a fifth of the total.

The rest, the part that is quietly most of the money, is getting the thing to exchange information with the software the business already runs on: the accounting package, the booking system, the field app, the twelve-year-old line-of-business application that a former employee configured and nobody has touched since.

It is also where the failures cluster. MIT’s Project NANDA, reviewing enterprise generative AI deployments in 2025, attributed most of the disappointing ones to brittle fit with existing workflows and systems instead of to model quality, though its headline failure figure has drawn published criticism for its methodology and for being generalised well past what it measured. Take the direction rather than the number.

This site has named integration as the largest single cost in a build, listed the failure modes in one paragraph, and stopped. This is that article.

Why the connecting is the expensive part

Three properties of ordinary business software explain it, and none is anybody’s fault.

Systems were bought at different times to solve different problems. The accounting package came first, the booking system arrived when the business grew, the field app was added when the crews got phones. Each was chosen well for its own job. Nobody was choosing a set.

They disagree about what things are. One system’s customer is a billing entity. Another’s is a site. A third’s is the person who answers the phone. The same job is a work order here, a project there, and a line item somewhere else. Reconciling those is not a technical problem, it is a definitional one, and it takes a person who understands the business instead of an engineer.

And most of them were built to be used by a person at a screen, not read by another program. That is the constraint that decides everything below.

The four routes in

When something needs to get information into or out of an existing system, there are four ways, and they differ enormously in cost and durability.

A documented interface. The vendor publishes a way for other software to read and write, with documentation. Best case by a wide margin. What matters is whether it covers the specific fields your project needs, which is a narrower question than whether it exists.

A scheduled export. The system produces a file on a timetable, to a folder or an email, and everything downstream reads that file. Unglamorous, frequently dismissed, and remarkably durable. It survives vendor changes that break other approaches, it is easy to inspect when something goes wrong, and for a great many business processes a file that lands every night at two is entirely sufficient. If someone proposes this and it fits, take it.

Direct database access. Where the vendor permits it and the system is hosted somewhere you can reach. Powerful, and it comes with a rule: read only. Writing directly into a database behind an application’s back bypasses every validation that application performs, and the damage from doing so is the kind that surfaces three weeks later in a report nobody can reconcile.

Browser automation. Software that drives the interface the way a person would, clicking through screens. It works, it is legitimate when the alternative is a person doing the same clicks, and it breaks whenever the vendor changes a layout. Treat it as a bridge with a maintenance cost instead of a solution, and never build a critical path on it without knowing that.

The choice among these is usually made for you by the vendor, which is the point people miss. Ask before designing, not after.

The four questions to ask a vendor

Most of what decides feasibility can be established in an afternoon of emails, and it is worth doing before anyone scopes anything.

Is production access available on my plan, or does it cost extra? A documented interface with access gated behind a sales conversation or a higher tier is a commercial constraint, and it belongs in the budget. This pattern is common enough across small-business software to be the default expectation rather than a surprise. It shows up in accommodation and booking systems as often as anywhere else.

Are the fields I need actually reachable? An interface that exposes bookings but not payments, or customers but not their history, may not cover the project. This is the question that most often turns a viable plan into a dead one, and it is answerable in a single email.

Can I write back, or only read? Reading is usually easier to get than writing, and a great many useful systems only need to read. Establish which you need before assuming.

What are the limits? How many requests, how often, and what happens when you exceed them. A system that needs to check two thousand records nightly against an interface allowing five hundred requests an hour is a design problem you want to find now.

Get the answers in writing, and date them. Vendor terms change, and a plan built on last year’s answer is a plan built on nothing.

Ownership, which is the question underneath

There is a question that sits beneath all of the above and gets asked far too late: can you get your own records out.

The specific version of the question: everything, in a usable format, on demand instead of on request, including the history, and what happens to it if you stop paying.

The contract answers this. A system you cannot export from is a system that holds part of your business, and that is worth knowing before building anything on top of it instead of during. The pattern that causes real damage is the business that builds an AI layer on a platform it cannot leave, and then discovers the platform’s pricing has changed and the exit costs more than the original problem.

This is the same instinct behind keeping your own systems and data under your control. The advantage a business builds from its own records only exists if it can actually reach them.

Reconciling what your systems disagree about

Assume the connections are all available. The largest remaining piece of work is usually the one that looks least like engineering.

Three systems hold customers. None shares an identifier. One has “Smith Contracting Ltd”, one has “Smith Contracting”, one has “J. Smith”. Two of those are the same entity and one is a different business with a similar name, and the only way to know is somebody who knows the customers.

This work has a shape. Decide which system is authoritative for each kind of record, so there is one answer to what a customer is. Establish or create a shared identifier. Work through the cases that do not match automatically, which will be more than expected and which are exactly the kind of thing that lands in an exception queue if there is no plan for them. And decide what happens on an ongoing basis when a new record is created in one system and not another.

That last part is the one that gets skipped. A one-time reconciliation degrades from the day it is finished unless something maintains it.

Budget for this properly. In most projects touching more than one system it is the largest single line I see, and the one most likely to be missing from a quote, because it looks like plumbing rather than intelligence and it is harder to make sound impressive. As a rough shape: on a $30,000 build touching three systems, the connections and the reconciliation routinely account for more than the AI work and the interface put together.

What to do when the answer is no

Sometimes the honest finding is that the integration is not viable. The vendor has no interface, will not permit database access, the export is a PDF designed for printing, and browser automation would break weekly.

Three responses, in order of preference.

Redesign the workflow around what is reachable. Often the valuable part of the job can be done with information that is available, and the unreachable system only needs the final result, which a person can enter in ten seconds. A build that automates eight of nine steps and leaves a person to key the result is worth far more than no build.

Move the boundary. If the unreachable system is genuinely central and genuinely closed, the real question stops being an AI question and becomes whether that system is the right one to keep. That is a larger conversation and sometimes the correct one.

Or stop. A project that requires an integration nobody can build is a project that should be declined instead of attempted, and finding that out in the first week costs an afternoon. Finding it out in the eighth week costs the budget.

Four answers before anyone designs anything

The AI is rarely what makes an AI project hard. The software you already own is.

Before anyone designs anything, four answers are worth having in writing: what each system will allow, which fields are actually reachable, whether you can get your own data out, and which system is authoritative when two of them disagree about the same customer. Those four turn a speculative plan into a scoped one, and they can be established in a few days for the cost of some emails.

The tell, when reading a proposal, is whether the integration section is specific. A proposal naming your systems, what it will use to reach each one, and what it will do about the records that do not match has done the work. A proposal saying it integrates with your existing systems has not made the phone calls yet, and the discovery is coming out of your budget instead of theirs.