Back home
Systems that stay

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.

01

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
02

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
03

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
04

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
05

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
06

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
Case study

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
What we built
  • 01Establishment resolution service
  • 02Review queue for weak matches
  • 03Change tracking against the register
How we work

How the work runs

  1. 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

  2. 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

  3. 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

  4. 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

when the scope is clear

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.

when the work is ongoing

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.

when the shape is still open

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.

A written data contract naming which system owns which field
Idempotent writes, so a retry cannot duplicate a record
Conflict rules agreed before the first sync runs
A dead-letter queue and replay, instead of silent failure
Monitoring on the flow, with an alert when it stops
A mapping document your own team can read

Send Inquiry

Regarding: Systems integration
What are you looking for? optional, pick as many as apply

By submitting this form, you agree to our Privacy Policy and Terms of Service.