05 November 2026
What changes when a domestic system is handed to a European client
The code does not change much when a system crosses into a European engagement. Everything around it does: where data may live, what may be shown, how a milestone becomes an invoice, who reads the documentation, and how a decision gets made across a seven-hour gap.
We have delivered to UK healthcare and to a global ERP vendor from teams in China. The engineering standard did not change between those projects and the domestic ones. The operating environment did, in six specific ways that are worth writing down before the first workshop rather than discovering at the first invoice.
Data residency is an architecture input, not a hosting preference
On the clinical patient management work, patient data never left the client infrastructure. That is a sentence about architecture, not about hosting: it decided where logging could be written, whether any third-party API could be called at runtime, where backups live, and which diagnostic path the support team is allowed to use when something breaks at 2 a.m.
Decide this in week one. Retrofitting locality onto a system designed to call external services is a rewrite of its data path, and the person who will ask the question is not the buyer — it is their security reviewer, usually late.
The NDA comes before the demo, not before the contract
A mutual NDA signed at kickoff governs what may be shown, screenshotted, published and said in a reference call. In practice it is the document that decides whether a case study like this one can exist, and in what detail.
Ask early what is publishable: the workflow, the numbers, the screens, the client name, nothing. The answer shapes what you capture during delivery. If you decide at the end that you would like a case study, the screenshots you need were taken eleven months ago and the client contact has moved.
A milestone becomes an invoice only when something is signed
Domestic delivery often runs on trust and a running account. European finance departments run on purchase order numbers, milestone acceptance and a document that a system can process. The difference is not bureaucracy; it is that payment terms are executed by people who never attend the project meeting.
Three habits follow. Get acceptance criteria for each milestone written before the milestone, not after. Treat a change request as a signed document, because scope that grows verbally is work that will not be invoiced. And keep model, licence and compute costs on a separate line where they apply, so that the first month of production traffic does not become an argument about whose budget it came from.
Bilingual documentation is not translation
Two audiences read the same project. Their engineering manager needs to know why a decision was made. The delivery team needs to know what to build. A document translated word for word serves neither, because the idioms that make a sentence natural in one language make it ambiguous in the other.
What works is narrower: one glossary, fixed once, with the same term used everywhere in both languages; short sentences; numbers with units; no humour and no metaphor in acceptance criteria. Decision records are written in both languages, briefly, rather than at length in one.
Handover is a test, not a session
Training that ends with a satisfied nod has proved that the trainer can explain the system. The real test is whether the client’s engineer can deploy, configure, roll back and diagnose without us in the room.
So the handover package is a runbook with the failure paths included, a deployment and rollback procedure, the monitoring that tells them something is wrong before a user does, and a named escalation path. We record the sessions and keep the written material current, and we ask them to perform a deployment while we watch. That last step is uncomfortable and it is the only one that predicts what happens after we leave.
The time zone decides the communication style
With a seven-hour gap, a meeting is expensive and a written update is cheap. Status by meeting is a schedule that puts someone in a call at 22:00 to hear information that could have been read at 09:00.
The habit that holds up: written-first, with a daily note that states what moved, what is blocked and what needs a decision; a fixed overlap window reserved for disagreement rather than for updates; and a decision log that both sides can point at later. Meetings then become what they should be — the place where a decision is made, not the place where information is transferred.
What does not change
The code still has to be tested, the migration still has to be reversible, and the estimate is still the estimate. Client expectations about quality do not vary by geography; what varies is how much of the surrounding work is implicit. In a domestic engagement much of it is carried by relationships and habit. Across a border it has to be documents, because the habits are not shared — and that, rather than any difference in engineering, is what a European handover actually costs.