Services / Data / Connecting systems

Every system you run, joined up, and kept that way

Your CRM, accounting package, online store, ad accounts and support desk feeding one reliable home for your numbers: connected properly, refreshed on a schedule, and loud about it when something fails.

Start the conversation →See the technology

Why it matters

The cost is the wait

Nobody set out to end up here. You bought a good CRM, a good accounting package, a good store platform and a good support desk, and each one is excellent at its own job. The trouble is that a customer exists separately in all four, spelled slightly differently in each, and no single system can tell you what that customer is actually worth. So somebody exports four files every month and joins them by hand, and the join is only as good as their patience that afternoon.

Connecting systems properly means more than an export button. It means pulling only what has changed so the sync is quick and cheap, keeping a full history so you can still answer questions about last March, matching records that describe the same customer under different names, coping when a vendor renames a field without warning, and knowing within minutes rather than weeks when a feed stops arriving. Most of the work is in the failure cases, because that is where the trust is won or lost.

The end of it is one organised home for your numbers where every figure can be traced back to the system it came from, step by step. "Where does this number come from?" gets answered by clicking, not by finding whoever built the spreadsheet three jobs ago.

What you actually get

Built to be trusted

Anyone can move data once. The value is in it still being right in eighteen months, after three of the source systems have changed underneath it.

Only what changed, every time

Feeds pull the new and updated records rather than re-downloading everything nightly. That keeps the sync fast, keeps API costs and rate limits under control, and means adding a fifth system does not double your data bill.

One customer, one record

The same person appearing as three slightly different rows across your CRM, store and helpdesk gets matched and merged under rules you agree, with the borderline cases surfaced for a human rather than guessed at, because a wrong merge is much harder to undo than a missed one.

History that survives the source

Once data is in your warehouse it stays there, with the shape it had at the time. You can still answer questions about last year after you migrate off a platform, and you keep your own numbers when a vendor's export limit or retention policy says otherwise.

Survives a vendor changing their mind

Feeds are built to notice when a source adds, renames or removes a field, and to flag it rather than silently drop a column. Schema changes are the single most common way a quiet pipeline starts producing quietly wrong numbers.

Checks on every load

Is it fresh, is it complete, are the values within sensible ranges, did a total drop by 80% overnight? Suspect loads are quarantined before they reach a dashboard, because a broken figure in a board pack costs credibility, not just money.

Traceable end to end

Every field on every report can be followed back through each transformation to the exact source record it came from. That makes audits straightforward and disagreements short. You look, rather than argue.

Where it earns its keep

Same pattern, different desks

Different industries, identical symptom: four good systems, none of which can answer the question the owner is actually asking.

01 · E-commerce & wholesale

Two sales channels that have never met

The problem: The online store, the wholesale orders typed into the accounting package, the ad accounts and the returns spreadsheet all count differently. Nobody can say what a product's true margin is after shipping, discounts, ad spend and returns, so pricing and buying decisions are made on gut feel.
What we build: Store, accounting package, ad platforms and the shipping provider all feeding one warehouse, with products matched across channels and a single agreed margin calculation applied to every order regardless of where it came from.
What changes: True margin per product and per channel, visible without a monthly export marathon, and the uncomfortable discovery of which best-sellers were losing money after returns.

02 · Clinics & healthcare groups

The patient who exists four times

The problem: Bookings, clinical notes, invoicing and the marketing list are separate systems with separate records. Reporting on activity means someone matching names and dates of birth in a spreadsheet, which is slow, error-prone and exactly the wrong place for personal data to end up.
What we build: Controlled feeds into a single warehouse with strict access rules, personal details minimised or pseudonymised for analysis, one patient identity resolved across systems, and every query logged. Clinical detail stays where it belongs; the reporting layer sees only what it needs.
What changes: Reliable activity, capacity and revenue reporting across sites, without personal data being copied into spreadsheets on people's laptops to get it.

03 · Field service & maintenance

Jobs in one app, money in another

The problem: Engineers log jobs and parts in a scheduling app, invoicing happens in the accounting package, and the two are reconciled monthly. Nobody knows which contracts are profitable until well after the renewal has been signed.
What we build: Job records, parts usage, engineer time and invoices joined in one place, with each job tied to its contract and customer, and automatic checks that flag jobs completed but never invoiced.
What changes: Profitability per contract and per engineer available continuously, plus the recovered revenue from work that was done and simply never billed.

The technology

The tools behind it, named

Ready-made connectors where they exist and are worth their price, custom feeds where they do not. Either way the data lands somewhere you own, in a form you can still read if we vanish.

5 layers · 36 technologies

Connectors & sync

Off-the-shelf integrations for the hundreds of common systems, with custom work reserved for the odd, old or in-house ones that no vendor supports.

Airbyte
Fivetran
n8n
Zapier
Make
Custom APIs

The systems we connect

The tools most businesses already run. Anything with an API can be connected; anything without one usually still has a scheduled export we can pick up reliably.

Salesforce
HubSpot
Shopify
WooCommerce
Stripe
Xero
QuickBooks
Zoho
Zendesk
Google Ads
Mailchimp
Google Sheets

Where it all lands

One organised home for your numbers, sized to your actual volumes. Not every business needs a cloud warehouse, and we will say so rather than sell you a bigger platform.

Google BigQuery
Snowflake
PostgreSQL
ClickHouse
Databricks
DuckDB

Cleaning & modelling

Where raw exports become the tidy, tested tables everything else reads from: deduplicated, typed, documented, and covered by tests that run on every load.

dbt
Python
pandas
Polars
SQLAlchemy
Great Expectations

Scheduling & reliability

The machinery that runs the loads on time, retries them when a source is down, catches up after an outage and tells a human when it genuinely cannot.

Apache Airflow
Dagster
Prefect
Apache Kafka
Sentry
Docker

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Typically six to ten weeks to a connected, tested set of feeds, and we start with the two systems that unlock the most, not all of them at once.

We audit what you actually run

Every system, every spreadsheet that has become a system, who owns it, what it holds and how good its API is. This nearly always turns up two or three tools nobody in the room knew were still being used for something important.

We agree the questions worth answering

Connecting everything for its own sake is expensive and dull. We pick the handful of questions that would change decisions (true margin, real cost per customer, activity per site) and connect only what those need first.

We look hard at your history

Before building anything permanent we profile what is actually in those systems: duplicates, blanks, dates in three formats, the year somebody changed how products were coded. You get an honest report, including where history is not worth keeping.

We build the first feeds end to end

Two systems, connected properly, with incremental syncs, tests, alerting and documented lineage, rather than ten systems half-connected. Once the pattern is right, the rest follow quickly and cheaply.

We reconcile against your own accounts

Totals are checked against your accounting package and the reports you already trust, and every discrepancy is explained. This step is where the credibility of everything downstream is established.

We hand over something maintainable

All feeds in your own cloud accounts, in readable code, in your repository, with a runbook for what to do when a source goes down. Adding the eleventh system later should not require us.

Before you commit

The questions worth asking

Will this really give us one source of truth?

Technically, yes, one place where all the data lives. Organisationally, only if your departments can agree on definitions, and that is the part that fails. If sales counts a deal at signature and finance counts it at invoice, no amount of engineering resolves the disagreement; it just moves it into the warehouse. We force those conversations early and write the answers down, but somebody in your business has to make the call. Projects that skip this ship a very expensive second version of the same argument.

How bad is our historical data likely to be?

Worse than you expect, in our experience. It usually is. Expect duplicates, records with mandatory fields left blank because the form allowed it, dates entered in different formats, and at least one point in the past where somebody changed how things were categorised without migrating what came before. We profile it up front and give you the honest picture, including where the sensible answer is to only report from a certain date forward rather than pretend the older data is comparable.

Do we have to replace any of our current systems?

No. The whole point is to leave your operational tools alone and read from them. Your team keeps working the way they work. Occasionally we find a tool whose data is genuinely unusable and recommend replacing it, but that is a separate decision and we will make the case rather than assume it.

What if one of our systems has no API?

Most still have a scheduled export, an emailed report or a database we can read, and any of those can be automated reliably. Where a system is truly sealed we will tell you plainly, and the honest answer is sometimes that a small amount of manual entry remains, but into one structured place, not four spreadsheets.

What does it cost to keep running?

Ongoing cost is storage, compute and any connector licences, and it depends heavily on volumes and refresh frequency. For most small and mid-sized businesses this lands in the tens of pounds a month rather than the thousands, because the data is smaller than people imagine. We model it with your real numbers during scoping and design to keep it there: incremental syncs, sensible refresh rates, and no warehouse bigger than you need.

Who owns the pipelines when the project ends?

You do. Everything runs in your cloud accounts, the code lives in your repository, and it is written to be read by whoever comes next. We would rather be kept because we are useful than because leaving is difficult.

Tell us which systems refuse to talk to each other

List the tools you run and the question you cannot currently answer. We will tell you which connections would answer it, and what shape your data is likely to be in.

Start the conversation →

Explore more

The rest of Data & Dashboards

Live dashboards Automated reporting Forecasting & alerts ← All of Data