System integration
APIs and integration layers that connect the systems you already run — including the ones with no API at all.
The challenge
Two systems hold the same record and neither is authoritative, so somebody exports from one and imports into the other every week — and quietly corrects the differences on the way.
The integration meant to fix that usually assumes both sides are available, correct and fast. What happens when they are not is the part nobody wrote down.
How we approach it
Name the system of record
Field by field, one side wins. Agreed in writing first.
Contract before code
The interface is specified and versioned before either side builds.
Design the failure case
Retries, ordering and duplicates handled, not hoped away.
Make every exchange visible
So a dispute is settled from the log, not from memory.
The same four phases, whatever we are building.
- 012–3 weeks
Discovery
We map your current process, users and constraints, then define scope in writing.
- 022–4 weeks
Design
Interface and data design, reviewed with the people who will use the system daily.
- 036 weeks+
Build
Delivery in two-week increments, each one testable, with progress visible throughout.
- 04Ongoing
Launch & support
Deployment, training and documentation, then optional support at a level you choose.
What you get
- The interface schema and rules, versioned on its own.
- The service that moves the data, in your repository.
- A scheduled check that both sides still agree.
- Retry, dead-letter and replay for exchanges that fail.
- Alerts on lag, failure rate and reconciliation drift.
- What to do when a system on the other side is down.
What changes
One record per field
Decided deliberately rather than by accident.
Fails loudly
A broken exchange raises an alert, not a silent gap.
Replayable
A failed message is reprocessed, not re-entered by hand.
Replaceable ends
Changing one system does not mean rebuilding the other.
Often looked at together.
About this work specifically.
General questions about scope, ownership and timelines are answered on the resources page.
Then we build the boundary around it — a read-only database view, a scheduled file exchange, or in the worst case a screen-level integration — and we document it as the compromise it is, so it can be replaced when a real interface exists.
It happens, and it changes the cost. Where a vendor will not supply documentation or a test environment we tell you at the assessment stage rather than absorbing the risk quietly and discovering it mid-build.
Tell us what you need built.
We reply within two working days with honest scope and next steps — including when we are not the right fit.