Skip to content

Systems integration

We connect your CRM, ERP, accounting software and the platforms you already use via API. We don't make you switch systems: we get the ones you have to understand each other.

One person points at a graph of connected nodes on a monitor while another types on a laptop, next to a barred window

There's a piece of data at your company that someone types twice. An order comes into the online shop and someone copies it into the management software. A sale is closed in the CRM and someone writes it again in the accounts. You're not missing a program: you have two that don't talk to each other and a person acting as the glue between them. Connecting them is the least glamorous work we do and the work that frees up the most time.

The least glamorous work frees up the most time

A WhatsApp assistant looks good in a meeting. A bridge between two programs is invisible: you still open the same screens, only the data is already there. That's why few people ask for it, and why it's worth looking at before other things: it removes a job that repeats every day and that nobody likes. Nobody boasts about no longer copying references from one place to another, but that's where the hours are really won back. And the smaller the business, the more it costs: according to Spain's National Statistics Institute (INE), more than half of Spanish companies have no employees at all. There, the glue between programs is you.

Source: INE (Spanish National Statistics Institute), Central Business Directory (DIRCE), data as at 1 January 2025

The right job isn't always a new program

People come to us asking for a new app and, when we look at the process, the two tools they need are already paid for and working: what's missing is for them to pass the data to each other. Building a program there is expensive and adds one more thing to maintain. The right job is smaller: an API integration that reads from one side and writes to the other, with a clear rule on which one wins when they disagree. It's less money for us and we say so anyway. And something is pushing in that direction: e-invoicing between businesses and self-employed professionals in Spain already has its regulation published in the Official State Gazette (BOE), and that data will have to travel in a structured format, not in a PDF someone types in again.

Source: Royal Decree 238/2026, e-invoicing between businesses and professionals (BOE)

You start by connecting two systems, not seven

Connecting everything at once is the plan most likely to be left half-done. Every system has its quirks: one returns everything in pages, another calls a customer what the next one calls an account, another limits how often you can query it per hour. Multiply that by seven and there's no project left. We start with the pair that hurts most, the one causing the most repeated typing or the most errors. It gets connected, left running for a few weeks, and we watch what it does with the odd cases, which always turn up. With that learnt, the second bridge costs less than the first. And sometimes, after the first, the rest are no longer needed.

What happens the day the other side changes its API?

An integration depends on something you don't control: the other company's software. Vendors change their APIs and retire old versions; some give plenty of notice and some less. When that happens, your bridge stops working, and the serious part is that it can stop silently: nobody notices until an order goes missing. Ask whoever quotes you, and ask us, before signing: who fixes the bridge if the third party changes, how you'll find out, and whether that's covered by maintenance or billed separately. We build it with monitoring, so if a connection fails or stops responding, an alert goes off.

What if your software won't let data in or out?

It happens, especially with older sector-specific software. There are degrees. If the vendor has an API but only offers it on its top plan, that's a sum to do before starting. If there's no API but it can export in a tidy, regular way, the bridge can be built on those files: less elegant, and it works. If you have access to its database, sometimes it can be read from there, read-only and carefully. And if none of the three is available, the honest answer is that it can't be done from that side, and then the conversation changes: replace that piece or work around it. We look at this before quoting, not halfway through.

What an integration isn't, and when it isn't worth it

It's worth not mixing up three things that look alike. Integration is moving data between programs that already hold it in order. Pulling the data out of a PDF delivery note or a scanned invoice is document automation. And opening those tools up to an AI model so it can look things up or act is an MCP server. Many projects end up with all three, but they're built separately. When isn't it worth it? When that data is typed twice a month: the bridge costs more than the typing. When the process is broken, because connecting it only spreads the mess faster. Tell us about your case and we'll tell you whether we can do it, how we'd approach it and what it would cost. If it isn't for us, we'll tell you that too.

Frequently asked questions

Don't Zapier or Make already do this?
For simple cases, yes, and if yours is one of those we'll tell you: we won't charge you for development when an off-the-shelf connector solves it. They fall short when the data needs transforming, when volume grows or when a system isn't on their list.
Do I have to change software?
No, the idea is the opposite: getting the ones you already use to understand each other. Switching systems is a project in its own right, with data migration and the team learning again. We only suggest it if the software is so closed there's no way to read from it or write to it.
What happens if a system goes down halfway?
It's designed on the assumption that it will, because it does. Anything that can't be delivered is queued and retried, and the retry doesn't duplicate: the classic failure of home-made integrations is the same order coming in three times. If something gets stuck, it alerts a person.
Who maintains the integration afterwards?
It's the most forgotten question, and it has to be put in writing before starting. An integration isn't installed and forgotten: it depends on two systems that evolve on their own. Your IT person can maintain it, with the code and documentation in hand, or we can.

How we work

  1. 01

    Understand

    We sit down with you and look at how you really work. We come away knowing what makes sense to build and, above all, what doesn't.

  2. 02

    Build

    We build it on the tools you already use and show it to you working, not in a slide deck.

  3. 03

    Stay with you

    We measure, we adjust and you can always reach us. Software isn't something you install and forget.

Other services