Most businesses do not have a software problem. They have six systems that each know something true, no agreement about which one wins, and a person in the middle keeping them roughly in step by hand.
Integration replaces that person with a defined flow: what moves, in which direction, how often, and what happens when the two sides disagree. That last question is the one that decides whether an integration holds up.
The connection is the easy part — these are the decisions that determine whether it holds up.
For every field that exists in two places, one system is authoritative and the other follows. Writing that down is the whole job, and it is a business decision rather than a technical one.
Knowing that this customer here is that customer there, when neither side shares an identifier. Where the match is guessed rather than keyed, the integration will quietly join the wrong things.
One-way is simpler, cheaper and fails in ways you can see. Two-way sync doubles the work and needs a rule for what happens when both sides change between runs — take it only where you need it.
Records that fail validation have to go somewhere a person will look, with enough context to fix them. An integration with no exception queue drops the awkward ones silently.
A count on both sides that has to agree, checked automatically and alerting when it does not. Silent failure is the expensive kind — you find out from a customer.
Networks drop. Anything that runs twice has to land once, which means every message carries a key the receiving side checks. Skipping this is how one outage becomes a week of cleaning up double entries.
For most businesses, connect systems directly first. Below about four systems, point-to-point is cheaper and easier to reason about than a platform.
Middleware earns its place as the count grows. Before either, check for a supported vendor connector that covers the fields you actually need.
The numbers before anything is quoted.
The Rapid Insight Workshop, fixed price. It prices the connections worth building, and the roadmap is yours whether or not you build with us.
One to two weeks to list every hand-off, export and re-key between your systems, with the hours attached and a name against each one.
Usually three to six weeks to the first connection running, between two systems with usable APIs. What stretches it is the two sides disagreeing about what a customer is.
APIs change and vendors retire versions. A small allowance for monitoring and fixes keeps a connection trusted. Defined work runs as Amplify; growing stacks as Apex.
Every hand-off between systems, including the ones done by email and the ones one person does on a Friday. The list is always longer than the one people describe from memory.
Field by field, which system wins. This is a decision meeting, not a build task, and an integration started before it happens will be rebuilt after it does.
The first connection ships with monitoring, an exception queue and a reconciliation count from day one — so the pattern the rest follow is already the safe one.
Each one is a page in its own right: what it does, when to buy instead of build, and what connecting it to the rest of the business actually involves.
The system that holds your money and stock, connected to everything else you run — and extended where it will not bend.
Sales sees stock and pricing without asking. Decide which system is right about the customer before either is connected.
What the floor is actually doing while the shift runs, instead of what the plan assumed and the ERP recorded the next morning.
Stock with a location instead of a number, directed picking, batch and expiry enforced — then reconciled against the ERP.
Scheduling, dispatch and capture on site, including an app that still works with no signal, invoiced out of the ERP.
One agreed number for what you will sell and make, instead of a sales figure and a production figure that never met.
What you own, what it has cost and what is due — with the parts and the costs landing back in the ERP.
Checks, non-conformances and corrective actions captured at the point of work, against the batch the ERP already knows about.
One copy of the data from every system, assembled on a schedule, so reporting stops depending on exports.
A fractional CTO — a senior technology leader part-time, owning your roadmap, managing your developers, and making the calls that cost real money when they go wrong.
We map how your business really runs — systems, costs, friction — and return a prioritised roadmap with a business case. $9,000 + GST, fixed.
Start with the free two-minute check — five questions, an honest read on where your business sits. Go deeper with a full assessment when you are ready to commit.
AI automation that handles judgement, not just fixed rules. We map the process first, then automate what actually slows your team down.
Not in the connection — in the disagreement. Two systems hold a slightly different version of the same customer, and nobody has decided which is authoritative. Until that is settled, syncing them faster only spreads the inconsistency more quickly.
It depends on how many systems you are joining and how much the logic between them matters. Two systems and a simple flow rarely justify a platform. Six systems, with rules about what happens in between, usually do.
There is almost always a way — a file drop, a database view, a scheduled export — and it is usually less elegant and more fragile. Worth knowing that going in, and worth checking a vendor's integration story before you buy the next system.
Monitoring and reconciliation, not hope. A good integration tells you when it fails and makes it easy to see what did not make it across. Silent failure is the expensive kind, because you find out from a customer.
A single well-understood connection between two systems with usable APIs is weeks, not months. What stretches it is discovering that the two sides disagree about what a customer or a product is, which is why the mapping and source-of-truth work happens before anyone estimates the build.
Integrate first, almost always. Connecting a system you already run is a fraction of the cost of replacing it, and it buys you the time to decide whether the replacement is genuinely needed. Replacement becomes the answer when the system cannot give up its data or cannot be changed at all — and then it is a modernisation project, not an integration one.
A small standing allowance, and it is the line most often left out of a quote. APIs change, vendors deprecate versions, and a connection nobody maintains fails quietly about a year in. The choice is a modest ongoing budget or a manual check every month, which is where you started.
Somebody named, on your side or ours. A connection nobody watches fails silently, and the usual discovery is three weeks later when a count will not reconcile. Handover includes who gets the alert and what they do with it — if that is undefined, the monitoring is decorative.
Often worth it. A connection built against a clean interface is a fraction of the cost of the replacement and buys you the time to decide whether the replacement is genuinely needed. What to avoid is deep custom work inside a system with a known end date — connect it, do not extend it.
Fix the disagreement before connecting anything. Pick the authoritative system field by field, reconcile the records once, then build the flow that keeps them in step. Connecting two systems around an unresolved difference does not resolve it — it just makes it happen faster.