
Systems integration, so the same fact is true everywhere.
One record, one owner, and every system agreeing on it.
Most businesses do not have a data problem, they have a copies problem: the customer exists in four systems, the stock figure depends on who you ask, and somebody reconciles it by hand every Monday. We connect the systems you are keeping so a change in one arrives correctly in the others, with a written agreement about which system owns which field. Replacing a system rather than connecting it is a different job, on the legacy modernization page.
The integrations we build
Different systems, same underlying question: who owns this fact, and what happens when two systems disagree about it.
ERP and finance systems
The system that owns the money, connected to everything that creates transactions. The hard part is rarely the connection, it is agreeing which side is authoritative for a price, a customer, or a stock figure.
- Orders, invoices, and credit notes
- Customer and supplier master data
- Stock levels and movements
- Reconciliation the finance team trusts
CRM and sales tooling
Keeping the commercial picture and the operational one in step, so nobody quotes a customer something operations cannot deliver, and nobody chases an account that already paid.
- Lead and account synchronisation
- Quote to order handover
- Product and price list sync
- Activity and support history
E-commerce, point of sale, and order flow
Where a delay is visible to a customer. Stock has to be right across channels, and an order placed online has to reach fulfilment without a person moving it between screens.
- Stock across every channel
- Order capture into fulfilment
- Payment and refund reconciliation
- Returns and exchange flows
Warehouse, logistics, and carriers
Physical movement reflected in software, and software reflected in physical movement. Usually involves at least one system whose interface is a scheduled file, which is a solved problem rather than a blocker.
- Warehouse and inventory systems
- Carrier booking and label generation
- Tracking and delivery status back
- File-based interfaces where that is all there is
HR, payroll, and identity
Joiners, movers, and leavers reaching every system that needs to know, which matters for payroll accuracy and matters more for access being removed on the day somebody leaves.
- Employee record synchronisation
- Access provisioning and removal
- Time, attendance, and payroll feeds
- Directory and single sign-on
Custom APIs for systems that have none
The older or more specialised system with no usable interface. We build one in front of it, working through its database or an export, so everything else can integrate against something documented and stable.
- An API layer over a closed system
- Database and export-based access
- A documented contract for other teams
- A seam to replace behind later
Mapping a vending estate to its legal establishments
A vending platform rather than an integration project, and it is here because the hard part is the same one. Every product had to be tied to a real supplier and checked against SIRET, the official French business register, then kept correct across every machine and reportable in one place.
Read the case study- 01Establishment resolution service
- 02Review queue for weak matches
- 03Change tracking against the register
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What makes an integration hold up
Every build ships end to end, from first scope to live deployment and ongoing support.


