London, England / Systems integration practice

The work is in the joint, not the box.

VEXBE LTD is an IT consultancy and systems integration practice. Most of what breaks in a business system is not inside any one application. It is at the seam: the export that silently truncates, the identity that means two different things either side of an interface, the nightly job nobody owns. That seam is the whole of our remit.

Name the two systems that won't talk Read the method

Name them to [email protected] and a written answer comes back inside three working days. The method, the commercial shape and the limits of what we take on are set out below, in the same words they appear in a proposal.

Registered: 17005285England and Wales
Classification: 62012 / 62020Software development, IT consultancy
Engagements: Assessment, delivery, retainedFixed price, or hours by the month
First reply: 3 working daysTo any seam described by email

Capability

Four kinds of work, described plainly enough to argue with.

Each of these is something we can start on a Monday and show progress on by Friday. An enquiry that sits outside all four gets told so, because widening a description to swallow it helps nobody.

Interface design and build

Point to point and broker mediated interfaces between systems that were never designed to meet. We define the contract first, in writing, including what happens to every field that can be absent, oversized or ambiguous, and only then write the transport.

REST, SOAP and file drop interfaces, including SFTP and fixed width legacies
Message queues and event streams where ordering and replay actually matter
Idempotency, retry and poison message handling specified before build
Contract tests that fail the pipeline, not a document that ages in a wiki

Data mapping and migration

Moving records from one shape to another without losing the ones that do not fit. The interesting part of a migration is never the ninety per cent that maps cleanly. It is the reconciliation of the rest, and the evidence that you can show an auditor afterwards.

Field level mapping documents with an owner named for every unmapped column
Dry runs against production shaped volumes before any cutover date is agreed
Row count and checksum reconciliation, retained as migration evidence
A rollback that has been rehearsed, not merely written down

Integration review and remediation

A short, bounded look at an estate that is already integrated and already hurting. The output is a written assessment with findings ranked by what would cost most if it failed on a Friday afternoon, plus a remediation sequence you can execute without us.

Inventory of live interfaces, owners, schedules and failure behaviour
Single points of failure and undocumented manual steps written down
Credential, certificate and expiry exposure across the integration surface
A prioritised remediation sequence with rough effort per item

Internal tooling and small software

Under SIC 62012 we also build the small pieces of software that sit around an integration: an operator console for a queue, a reconciliation report, an approval step that currently lives in somebody's inbox. Small, specific and handed over with the source.

Operational consoles and admin surfaces for systems that have none
Scheduled reconciliation and exception reporting
Deployment and runbook automation for the interfaces we build
Source, build instructions and licence transferred at completion

Method

Write the contract before writing the code.

Integration failures are almost always agreement failures that surfaced late. Two teams held different beliefs about a field, a timezone, or who was allowed to retry, and nothing forced them to compare notes until production did it for them.

So the first deliverable of any engagement here is a written interface contract, and it is signed off by a person on each side of the seam before implementation starts. It is short. It is specific. It is boring on purpose.

What the contract has to settle

Identity: Which key is authoritative on each side, what happens when they disagree, and who resolves it.
Absence: The difference between a field that is empty, a field that is unknown and a field that was never sent.
Time: Stated timezone and offset handling, clock skew tolerance, and what "as at" means on each record.
Volume: Expected and peak throughput, maximum payload, and the agreed behaviour when either is exceeded.
Failure: Retry policy, idempotency key, dead letter destination, and the named human who is paged.
Change: How either side gives notice of a breaking change, and the minimum notice period both accept.

Commercial shape

Three ways an engagement is structured.

We publish the shape rather than a rate card, because the rate depends on the estate and we will not pretend otherwise. Rates are quoted in writing before any work starts and do not change mid engagement without a signed variation.

Engagement structures offered by VEXBE LTD as at 7 August 2026
Structure	Typical duration	What you receive	How it ends	Suits
Assessment	One to three weeks, fixed price	Written assessment of the integration surface, ranked findings, remediation sequence with rough effort per item	On delivery of the document. No obligation to continue and no notice period	An estate that already works but nobody wants to touch
Delivery	Scoped per piece of work, fixed price against a signed contract document	The interface or migration itself, its tests, its runbook and its source, plus handover to a named owner on your side	On acceptance against the written criteria agreed at the start	A defined seam that has to be specified, delivered and handed over
Retained hours	Monthly, minimum three months, rolling	An agreed block of hours per month against a shared backlog you prioritise, with unused hours neither banked nor refunded	Thirty days written notice from either side	Ongoing change against interfaces we already built

Every engagement is governed by a written agreement. We do not begin chargeable work on the strength of a purchase order alone, and we do not accept engagements where the scope is expected to be discovered as we go without a variation route agreed in advance.

On the record

Everything here is checkable.

This site publishes the things a buyer can test before spending anything: how the work is sequenced, what the interface contract has to settle, and what the register says about the company.

What is written down

The six clauses an interface contract has to settle. The three structures an engagement can take and how each one ends. The acceptance route a delivery is measured against. All of it is on this page, in the same words it appears in a proposal.

What you can verify today

Number, registered office, filing history and officer particulars are all filed with the registrar and free to read. None of the officer detail is restated here. Search 17005285 and read the filings at source instead of accepting what a company writes about itself.

Sequence

How a first engagement runs, start to finish.

This is the sequence for a delivery engagement. An assessment stops after step four with a document instead of a build.

Step one / no charge
You describe one seam

An email describing a single integration problem: which two systems, what is supposed to happen between them, and what actually happens. We reply within three working days saying whether it is work we can do. Sometimes the honest answer is that your incumbent supplier should fix it under an existing contract, and we will say that.
Step two / no charge
One call, forty five minutes

Enough to understand the estate around the seam, the constraints nobody wrote down, and who has to agree to a change. No slides. If we cannot describe the problem back to you accurately by the end of it, we are not ready to quote.
Step three
A written proposal with a fixed price

Scope, exclusions, assumptions, acceptance criteria, price and dates, in a document short enough to read in one sitting. The exclusions section is the important one and it is written to be read, not to be hidden behind.
Step four
The interface contract

Before code, the contract document covering identity, absence, time, volume, failure and change, agreed by a named person on each side of the seam. This is where most of the risk in the engagement is removed.
Step five
Build, in the open

Work happens in your repository, in your environments, against your pipeline where one exists. A short written note every week: what moved, what is blocked, what changed in the estimate. No status meeting is required to find out where the work stands.
Step six
Handover, then absence

Acceptance against the criteria in the proposal, a runbook written for whoever is on call rather than for us, and a named owner on your side who has run the thing at least once with us watching. Then we leave. A supplier you cannot get rid of is a defect.

Questions we expect

The awkward ones, answered first.

How do we test the thinking before committing a budget to it?

Take an assessment. The deliverable is a document you read before deciding anything further, at a fixed price, with no notice period and no lock in, which is a small and bounded way to find out whether the thinking is any good. A delivery engagement is priced against written acceptance criteria, so the risk of the estimate being wrong sits with us rather than with you.

Who will actually do the work?

Work is carried out by VEXBE LTD personnel and, where an engagement requires it, by named subcontractors disclosed to you in writing before they start. Individuals are not named on this website. Particulars of the officers are filed under 17005285 and readable at source.

What happens to the code and the documents at the end?

Deliverables built specifically for you transfer to you on payment in full, along with source and build instructions. Where we reuse a pre existing component of our own, you get a perpetual licence to use and modify it for the purpose of the engagement, and that component is identified in the proposal rather than discovered later. This is set out in the terms.

Will you work under our client's contract and insurance requirements?

We will read them and answer in writing. Insurance and any contractual requirements you need a supplier to meet are settled during procurement, before anything is signed, rather than asserted on a web page.

Start here

Name the two systems that won't talk.

Which two systems are supposed to talk to each other, and what happens instead. Two sentences to [email protected] buys a straight written answer on whether this is work we can do, and it lands inside three working days.

Email [email protected] What to put in it