service
Software integrations
A business running several systems that do not talk to each other, where staff copy data between them and the copies disagree.
What you get
- An inventory of the systems, what each owns, and which one is authoritative for each field.
- Working integration for the field mappings that matter, with retries and failure visibility.
- A written statement of what is synchronised, how often, and what happens when a record conflicts.
- Monitoring so a broken connection is noticed the same day.
How this differs from business automation
An integration is plumbing between systems; automation is the decision of what should happen. Most integration projects stall on the question "which system owns this field", which is a decision rather than a technical problem.
How we approach it
- We document both systems and their rate limits before writing a connector, because the limit is usually what determines the design.
- We decide which system is authoritative for each field, since two-way sync without an owner produces silent conflicts.
- We build for replay and reconciliation: when a sync fails, the recovery path is designed rather than improvised.
What is out of scope
- Integrating with a system whose API is undocumented or whose terms prohibit it. We will identify the constraint rather than work around it.
- Two-way sync of every field. Usually one system should own each field, and bidirectional sync creates conflicts nobody can resolve.
How it is priced
Cost is driven by the rate limits and data models of the systems involved, and by whether either side can be changed.
See the pricing page for how that works in practice.
How to start
The first conversation is free and usually takes half an hour. Bring the problem as you experience it — what is not working and what you have already tried.
Tell us what you need
The more specific you are about the problem, the more useful the first reply will be. We read every enquiry ourselves.