Can I get a custom tool that talks to the software I already pay for?

Most small businesses do not need new software. They need the software they already have to stop being three separate islands.

The booking system knows about appointments. The accounting package needs to know about them. The spreadsheet somebody keeps knows about the bit neither of them covers. Currently the bridge between all three is a person, retyping, on a Tuesday.

Connecting things you already pay for is frequently the best value in small business software, because you are not replacing anything, nobody has to learn a new system, and the job is small.

Whether it can be done comes down to one question: will your systems let anything else in?

The four ways in, best first

A proper API. “Application programming interface” — a documented way for other software to ask your system questions and give it instructions. If a product has one, connecting to it is ordinary work. Most modern business software does: booking systems, accounting packages, point of sale, CRMs, email tools. This is the good case and it is more common than people expect.

A scheduled export. No API, but the system can email or drop a file somewhere on a schedule. Less elegant, works fine. A tool picks up the file, reads it, does the job. Most tasks that involve a weekly report fit here comfortably.

A manual export. Somebody clicks “download” and the tool takes it from there. This still removes most of the work — the reading, the checking, the retyping — and leaves one click. Worth doing when the alternative is nothing.

Screen-scraping. No way in at all, so software pretends to be a person clicking through the interface. It works, and I avoid it unless there is no alternative. It breaks whenever the vendor changes a screen, which they do without telling you, and then you own a tool that fails silently.

The first three are all fine. If you land on the fourth, the honest advice is often to change the software rather than build a bridge to it.

How to find out, before you talk to anybody

You can answer this yourself in twenty minutes per system:

Search for the product name plus “API” or “developer”. If a documentation site comes up, that is your answer and it is a good one.

Look in the settings for “Integrations”, “API keys”, or “Developer”. If you can generate a key, there is a way in.

Check whether it already connects to things. If your product advertises connections to other tools, the machinery exists.

Look at the export options. Under reports or settings — can you get a CSV or Excel file out, and can it be scheduled?

Then just ask their support. “Do you have an API, and is it available on my plan?” That last clause matters, and it is the part that catches people out.

The things that actually go wrong

Not the technology. These:

The API is on a higher tier. Extremely common. The connection is possible and unlocking it costs more per month than you expected. Find this out first, because it can change the whole calculation.

Limits on how often you can ask. Most APIs cap requests. Rarely a problem for a small tool, occasionally a problem if you wanted to move years of history at once.

Nobody knows who owns the account. The system was set up by somebody who left. This is a surprisingly frequent hold-up and it is entirely administrative.

The two systems disagree about the same thing. Both hold customer records and they do not match — different spellings, duplicates, one has a phone number the other lacks. Deciding which one is right is not a technical question, it is yours, and it is usually the longest conversation in the project.

It is a medical or financial system. Then there are rules about what may be connected to what, and paperwork that has to be signed before anybody writes a line. Worth knowing at the start rather than the middle. I will not touch a system holding patient records without the appropriate agreement signed first — not because it is awkward, but because it is the law.

What these connections usually turn out to be

In practice, the useful ones are unglamorous:

• Stop the retyping. Something happens in system A, so the matching thing appears in system B. No person in the middle.
• Check one against the other. Pull what was ordered and what was invoiced and flag where they disagree. Cheap to build, and it catches things that cost money.
• One view of two systems. A single page showing today’s appointments alongside whether each has paid — which neither product will show you because each only knows half.
• Notify somebody when something specific happens. Not everything. One thing, to one person, that they currently find out about too late.
• Ask a plain question of your own records. Modern tools have made this genuinely achievable, and for a business sitting on years of history in a system with a bad search box, it is often the most valuable thing on the list.

Why this is usually cheaper than it sounds

You are not replacing anything, so there is no migration and no retraining. You are not designing an interface, because often there barely is one — the tool runs on a schedule and the only thing anybody sees is that the job stopped needing doing. And the systems already contain the data, so nobody is entering anything.

The cost is in working out exactly what should happen, which is a conversation rather than a construction project. I will not print a number here, because it depends entirely on which of the four ways in you have and how much the two systems disagree with each other — but these are among the smallest jobs I take on.

What to bring if you want an answer

If you want to know whether your particular case works, the useful things to know are:

1. Which systems, by name and by plan
2. What moves between them now, and who moves it
3. How often
4. What you found when you searched for each product plus “API”

With those four, I can usually tell you in one conversation whether it is straightforward, awkward, or not worth it. Sometimes the answer is that the vendor already sells the connection you want and you should buy theirs. That happens, and I would rather say so.

The short version

If the software you already pay for has a documented way in — and most modern products do — connecting two of them is ordinary, small work. Check for an API and check which plan it is on before anything else. Avoid anything that depends on pretending to be a person clicking. And expect the hardest part to be deciding which system is right when they disagree.

Tell me which two systems you are trying to get talking and what currently moves between them. I will tell you which of the four ways in you have got, and whether it is worth doing.