Integrations

Two systems that don’t talk to each other.

You have an accounting package, a webshop, a scheduling tool or an ERP. Each does its job. They just know nothing about each other, so every week someone types the same data in a second time.

An integration solves that without replacing anything. It is almost always faster and cheaper than moving to one package that is supposed to do everything.


What an integration usually does

  • Orders from a webshop into the accounting package.
  • Invoices and payments back into your own system.
  • Customer records kept in one place instead of three.
  • Stock that stays correct even when you sell in two places.
  • Hours and work orders arriving at invoicing on their own.

Which packages they are matters less than whether they open a door. Exact Online, Teamleader, Odoo, WooCommerce, Shopify and most common systems do, each in their own way.

What gets checked first

Before a single line of code is written, four things have to be settled:

  • Does each system have an API or an export to work from?
  • Which system owns a record when the two disagree?
  • How often does it need to sync: immediately, or is once a night enough?
  • What happens if the integration stops for a day?

That last question is the one most often skipped, and it causes the most work later. An integration that fails silently is worse than none at all, because everyone carries on assuming the numbers still add up.

Honest about the limit

When an integration isn’t the answer

  • When the package already offers the integration off the shelf. Then you just switch it on.
  • When one of the two systems is being replaced within the year anyway.
  • When it covers something that happens three times a month. Retyping is cheaper.

Why this is familiar ground

We are part-owners of Veton, a Belgian manufacturer of EV chargers. For a large fleet of devices that chain runs all the way through: from the device in the field, through the cloud platform, into the ERP, the invoicing and the reporting.

Integrations are not a side concern there. They are how the thing works, and they have to keep running while nobody is watching.

Starting with the two days

The first step is 2 days on site: which systems you use, what they do and don't allow, and what an integration between them would be worth. You get concrete advice, and the honest answer if it isn't worth doing.

€1,300

2 days · excl. VAT

Introductory rate for the first 10 projects

Frequently asked questions

What if our package has no API?

There is usually still an export, an import format or a webhook to work with. What is actually possible gets checked before anything is built. If there genuinely is no door, you will hear that, and an integration simply is not an option.

Who owns the integration afterwards?

You do. The code and the credentials stay yours, and the integration runs on your own environment or hosting. No subscription ends up sitting between you and your own data.

What if one of the two packages changes?

Then the integration may need adjusting. Vendors change their APIs, so an integration is not a one-off project but something that needs occasional maintenance. That happens at the same day rate (€650/day), with no fixed contract.

How long does it take to build one?

That depends on the two systems and on how much has to travel between them. A first estimate is part of the two days (€1,300, excl. VAT): in 2 days it becomes clear what is going on, including one small working piece running on your own data.

Which two systems are they?

Half an hour is enough to know whether an integration is technically possible, and whether it is worth doing.