Your systems work.
Just not together.
For companies where the same data sits in three programmes and someone retypes it every week. An integration makes your existing systems talk: orders into your bookkeeping, stock into your webshop, customers into your CRM. Build it once and it is done.
What disconnected systems cost you.
The same data entered three times
An order in your webshop, the same order in your bookkeeping, and the customer details again in your CRM. Every time a chance of a typo.
Numbers that disagree
Your stock says one thing and your webshop another, your revenue one thing and your invoices another. Nobody knows which source leads.
Work that only happens on Monday
Orders processed only once someone is at a desk. Meanwhile nothing is ready for the warehouse.
Zapier chains that quietly stop
An automation that worked for months and now fails on every exception, without anyone seeing an error.
A package that 'has an integration'
There is a standard connector, but not with the fields you use. So part of it stays manual.
Growth means more retyping
Twice the orders means twice the data entry. That is exactly the kind of work that should not scale with you.
From separate to connected.
Deciding what the source is
One place per type of data where it is correct: articles there, customers here, stock over there. Without that choice you build an integration that lets two systems win by turns.
Checking what the systems can do
Does the package have an API, an export, a webhook or only a screen? That decides whether it can be live or hourly, and you hear it before anything is built.
Building with error handling
The hard part is not the happy path but the exception: a system briefly down, a duplicate order, an empty field. Those get caught, logged and retried.
Keeping it visible
A small overview of what synchronised and what failed, plus an alert when something stays stuck. A silent integration is a dangerous integration.
- ✓One source per type of data
- ✓Automatic instead of retyped
- ✓Error handling and retries
- ✓Visibility of what did and did not go through
- ✓A test environment beside production
- ✓Code in your repository
A single integration is often a small project with a fixed price. Send me which two systems and what has to move between them, and you will hear quickly what it costs.
What usually gets connected
Most integrations I build sit between four kinds of systems. Which combination it is mainly determines how many exceptions are involved, not how long it takes.
Webshop and bookkeeping
Orders, invoices and payments automatically into Moneybird, Exact or a comparable package, including VAT rates per product type.
Stock and sales channels
One stock level feeding webshop, till and marketplaces, so you do not sell what is not there.
CRM and quotes
Enquiries landing as a customer and a quote in your CRM, with the status coming back once it is signed.
Payments and subscriptions
Stripe or Mollie for one-off payments, subscriptions and direct debit, with the admin adding up by itself. See [Stripe integration](/techniek/stripe-koppeling-laten-bouwen) and [Mollie integration](/techniek/mollie-koppeling-laten-bouwen).
When Zapier or Make is enough
For simple steps between two modern tools, Zapier and Make are fine and cheaper than what I do. A form submission into a spreadsheet, a new customer into your mailing list: you do not need that built.
It pinches once logic arrives: fields that must be filled differently per situation, duplicate records you want to catch, or volume where you start paying per task. Then a custom integration is more predictable and cheaper over time.
- ✓Low volume and simple steps: Zapier or Make
- ✓Own logic or many exceptions: build it
- ✓Sensitive data: preferably not through a middleman
- ✓Volume that keeps growing: custom integration
Where integrations go wrong
Almost always at the same point: someone thought about what happens when everything works, and not about what happens when it does not. A system down for ten minutes, an order arriving twice, a customer named differently in each system.
So every integration comes with a log, an error that lands somewhere and a way to rerun something without redoing everything. That costs a small part of the work and saves you the kind of problem you only notice three weeks later.
One-off work or part of a project
An integration does not have to be attached to a bigger track; it is one of the few things I also take on as a standalone job. What I build with and which systems I connect most often is on tech.
If the integration sits inside something bigger, it usually belongs with custom software, a client portal or a B2B webshop.
What does a custom integration cost?
Does it work with an old package without an API?
Is Zapier not cheaper?
How do I know it keeps working?
Do you do integrations without a wider project?
How long does it take?
Tell me what you
want to build.
A half-hour call. You get an honest answer about what it costs, how long it takes and whether building it is smart at all.