Your Systems Work. They Just Don’t Work Together.
Your website knows the order. The warehouse knows the stock. The accounts package knows the payment. The CRM knows the customer. And somebody on your team is still moving information between them by hand.
Does this sound familiar?
The same order is typed into two systems, and occasionally into a third.
Stock is right in one place and wrong in another, and nobody is sure which to believe.
A monthly report takes half a day because the numbers live in four platforms.
A customer asks where their order is and the answer needs three screens.
You have bought good software twice and still have a gap in the middle.
A member of staff has become the integration, and they are about to go on holiday.
Nobody sets out to buy a gap
Systems arrive one at a time, and each one is bought to solve its own problem. The shop needs a storefront. Finance needs an accounts package. The warehouse needs stock control. Each decision is sensible on the day it is made, and each is made by different people at different times.
What nobody buys is the space between them. So it gets filled by a person — someone who knows that the order number in one system is the reference in another, that Tuesday’s export has to be edited before it will import, and that the stock figure is only trustworthy after the morning sync. That knowledge is rarely written down.
It works until volume rises, or until that person leaves. The failure is quiet: information is not lost, it is just late, or entered twice, or subtly different in two places. By the time anyone notices, the workaround is the process.
You may already have the right systems
The first question is not what to replace. It is what already talks, and what only needs to be asked properly. Most platforms bought in the last decade have an API, and where two systems both have one, connecting them is a fraction of the cost and risk of replacing either.
So we will sometimes recommend doing less. If your accounts package and your storefront both expose what the other needs, the answer is an integration and not a new platform. If a process runs twice a year and takes an hour, automating it may cost more than it saves, and we will say so. The work worth doing is the work that removes a daily cost, not the work that looks most impressive on a diagram.
Where the cost is the copying and pasting itself rather than the connection, that is a process automation problem, and the answer may be smaller still.
One system owns each fact
The hard part of integration is not moving data. It is deciding which system is right when two disagree — and they will disagree, because they were updated seconds apart by different people for different reasons.
So the first piece of design work is ownership: the storefront owns the order, the warehouse owns the stock figure, the accounts package owns whether it has been paid. Everything else holds a copy, and a copy is never allowed to overwrite the original. Where a conflict is genuinely possible, it is raised for a person rather than resolved silently by whichever process ran last.
An API is one system asking another for information. A webhook is one system telling another that something has happened, without being asked. A scheduled process checks or synchronises at an interval that suits the data. Most real integrations use all three, because not everything needs to happen instantly: a stock figure might, and last month’s reporting almost certainly does not.
When there is no API
Older and specialist systems — the ones running a particular industry, or written for one company years ago — often have no API at all. That does not put them out of reach.
Depending on what the system allows, the route in may be a direct database interface, a scheduled and secured file exchange, a piece of middleware that speaks to both sides, or a custom connector written for that system specifically. We have taken this route often enough to know which approaches age well and which quietly become another thing to maintain.
How we approach it
Understand
Map what exists: the systems, the data each one owns, and the manual steps people have built around them.
Decide
Agree what should be connected, what should stay as it is, and what is not worth automating at all.
Build
Implement the connection — API, webhook, scheduled process or custom connector, whichever the systems actually support.
Move
Run old and new alongside each other, reconcile the results, and cut over once the numbers agree.
Stay
Monitor it, fix it when a supplier changes their API, and keep improving it. We build it, we run it, we stay.
We’ve solved this before
Urban Industry — streetwear retail, Eastbourne
Urban Industry sells 2,500 products from more than a hundred brands, through their own store, through marketplaces and in person. The problem was not any single platform — it was that stock, orders and fulfilment lived in different places, and the business was growing faster than anyone could reconcile them by hand.
The chain that had to hold is simple to describe and hard to run by hand: store → payment → stock and order management → fulfilment. Every handover in it was a person.
We built a B2C platform that gives the team one view of stock, orders and fulfilment across every sales channel, and connected it outward: PayPal and Checkout by Amazon for payment, a custom storefront as a premium seller on Amazon UK, and MetaPack — one of the largest shipment platforms — so orders reach customers worldwide by the method that suits them.
What this usually involves
API & Integration
Connecting the systems you already use, so they stop needing a person in the middle.
Questions we get asked
Can you integrate software built by someone else?
Usually, yes — most of this work involves systems we did not build. What matters is what the system exposes and what access we can be given, not who wrote it.
What if one of our systems has no API?
Then we look at a database interface, a secured file exchange, middleware, or a connector written for that system. It is more work than a documented API, and we will tell you which of those it is before we start.
Do we have to replace anything?
Often not. If the systems you have are doing their jobs, the answer is the connection between them. We would rather tell you that than sell you a rebuild.
How long does an integration take?
It depends almost entirely on the worst-documented system involved. A connection between two modern platforms can take days; one involving an undocumented legacy database takes longer, and most of that time is spent understanding it rather than writing code.
Will you support it afterwards?
Yes. Integrations break when somebody else changes their API, which is not a question of if. We monitor the ones we build and fix them when that happens.
Tell us which systems need to talk.
You don’t need to know the technical answer yet. Tell us what is causing the problem. We’ll start there.
Building and running business systems since 2000. The same team that builds it stays to run it.
Start a Conversation