Managing an engagement with a non-EU freelancer: the delivery guide

A non-EU engagement rarely goes off track all at once: it becomes fragile when the specification remains vague, IT systems access arrives too late, the activity report becomes a formality and acceptance has not been thought through from the start.

Managing an engagement with a non-EU freelancer therefore requires a simple discipline: make the work verifiable, limit grey areas and organise day-to-day delivery without turning the relationship into disguised employment.

The aim is not to over-control.
The aim is to secure delivery.

Clarify the operational framework before kick-off

Management starts before the first project meeting.

Before launching the engagement, the IT services firm must have a usable scope: objectives, deliverables, client constraints, acceptance criteria, dependencies, tools, contacts and communication rules.

This operational framing must be consistent with the engagement framework and shared expectations with a French IT services firm. Day-to-day management should not compensate for initial vagueness.

Turn the need into an actionable specification

A useful specification is not a fixed administrative document.

It must allow the freelancer to understand:

• what is expected;
• what is excluded;
• the deliverables to be produced;
• the acceptance criteria;
• dependencies on the IT services firm or end-client side;
• security, architecture or documentation constraints;
• validation milestones.

For a tech engagement, the specification must also state the environments concerned, coding standards, review workflows, ticketing tools, testing requirements and knowledge transfer arrangements.

A good specification reduces misunderstandings.
It must not become a job description. It describes a service, deliverables and expected outcomes.

Align the purchase order with actual delivery

The purchase order must not be a simple fixed-fee line.

It must reflect the reality of the engagement: scope, duration, deliverables, validation conditions, reporting arrangements, confidentiality obligations and reversibility rules.

This is particularly important when the IT services firm has itself committed to an end client. Management must remain consistent with how to structure the framework agreement and purchase orders, so as to avoid a gap between what is sold, what is bought and what is actually managed.

The right reflex: translate commercial commitments into verifiable delivery rules.

Organise a kick-off that avoids ambiguity

The kick-off is not a symbolic start-up meeting.

It is the moment when the IT services firm sets the collaboration framework, decision-making channels and validation rules.

Points to cover from the first discussion

The kick-off must cover at least:

• the client context and business issues;
• the scope of the engagement;
• the expected deliverables;
• the tools used;
• IT systems access rules;
• contacts on the IT services firm and end-client side;
• communication channels;
• the monitoring rhythm;
• activity report rules;
• acceptance arrangements;
• reversibility conditions;
• offboarding rules.

Each point must be documented.
A short summary is enough, provided it is shared and validated.

Identify the person responsible for validation

An offshore engagement quickly becomes complicated when no one knows who validates what.

You need to distinguish between:

• the operational contact;
• the functional validator;
• the technical lead;
• the security contact;
• the access manager;
• the person who validates the activity report or progress.

This clarification avoids implicit validations, contradictory feedback and acceptance delays.

The non-EU freelancer must not depend on scattered instructions.
Management must be clear, documented and tied to the agreed service.

Manage exchanges without creating excessive operational dependency

A non-EU freelancer can be highly integrated into delivery without being treated as an employee.

The distinction lies in the organisation.

The IT services firm manages a service. It must not recreate the reflexes of internal management: working hours imposed as for an employee, permanent approval of absences, hierarchical integration, disciplinary sanctions or attachment to an internal organisation chart.

To keep a healthy boundary, it is useful to know the signs of subordination to avoid when organising an engagement.

Prefer clear objectives over permanent control

Good management is based on:

• well-qualified tickets;
• identified deliverables;
• done criteria;
• regular progress points;
• formalised validations;
• traceable decisions.

Poor management is based on:

• permanent oral instructions;
• undocumented changes;
• implicit availability;
• informal validations;
• confusion between project management and HR management.

The freelancer must know what they have to produce, by when, to which standards and with which dependencies.

They must not be placed in a logic of day-to-day hierarchical execution.

Formalise scope changes

Scope creep is common in tech engagements.

An added ticket, a client emergency, technical debt remediation or a production fix may change the actual workload.

The reflex to establish: any significant change must be tracked.

This can be done through:

• a dedicated ticket;
• a decision note;
• a backlog update;
• an exchange validated in writing;
• an amendment or a new purchase order if the scope genuinely changes.

This point is even more sensitive when the end client imposes specific constraints. Operational management must remain aligned with back-to-back contracts explained, without transferring obligations to the freelancer that were not provided for in the chain.

Manage time-zone differences with asynchronous exchanges

Time-zone differences are not a problem in themselves.

They become a risk when the team operates only orally, in emergency mode or with untracked decisions.

A freelancer based in Dubai, Bali or another non-EU location can contribute effectively if the workflow limits dependency on synchronous meetings.

Put writing at the centre of delivery

Asynchronous exchanges must become the foundation of management.

In practice, the IT services firm should favour:

• complete tickets;
• explicit acceptance criteria;
• contextualised comments;
• written decisions;
• short summaries;
• visible progress statuses;
• living documentation.

Writing reduces information loss.
It also protects the IT services firm in the event of a disagreement over a deliverable, a delay or an unforeseen request.

Define reasonable overlap windows

It is useful to provide overlap windows for critical points: decisions, incidents, technical reviews, demonstrations and acceptance.

These windows must be realistic and compatible with the freelancer’s location.

The objective is not to impose French internal working hours.
The objective is to prevent every decision from blocking twenty-four hours of delivery.

The right balance: few meetings, but useful meetings.
Every meeting must produce a decision, a validation or a traceable action.

Track progress with a usable activity report

The activity report is not just an administrative document.

Used properly, it becomes a management tool.

It allows the IT services firm to verify progress, document the service, identify blockers and reconcile the work carried out with the expected deliverables.

What an activity report should contain

A useful activity report must remain factual.

It may mention:

• the periods worked;
• the tasks completed;
• the tickets handled;
• the deliverables produced;
• the blockers encountered;
• dependencies on the IT services firm or client side;
• items awaiting validation;
• any discrepancies with the planned scope.

It must not become a micro-management tool.

The activity report must support the management of a service.
It must not mimic internal HR monitoring.

Validate the activity report before the end of the engagement

A frequent mistake is to discover discrepancies at the invoicing or closing stage.

The activity report must be reviewed regularly, with a simple logic:

• what is validated;
• what is disputed;
• what requires clarification;
• what relates to a scope change;
• what must be put back into the backlog.

This discipline avoids late-stage discussions about the reality of the work performed.

It also makes it possible to detect delays, unresolved dependencies or requests that fall outside the specification quickly.

Prepare acceptance from the start

Acceptance must not be postponed until the end.

If acceptance criteria are not defined from the outset, validation becomes subjective.
The end client may refuse a deliverable for undocumented reasons.
The IT services firm then finds itself exposed to an operational dispute that is difficult to arbitrate.

Define acceptance criteria

Each significant deliverable must be associated with acceptance criteria.

Depending on the engagement, these criteria may relate to:

• the expected operation;
• unit or functional tests;
• performance;
• security;
• compatibility with the existing environment;
• documentation;
• code quality;
• continuous integration rules;
• compliance with the end client’s standards.

These criteria must be accessible to the freelancer from the start.

They must also be shared with the people responsible for validation.

Handle reservations in a structured way

Acceptance may lead to validation, refusal or validation with reservations.

Reservations must be:

• precise;
• tied to an acceptance criterion;
• documented;
• prioritised;
• assigned a reasonable correction deadline.

A vague reservation such as “this is not compliant” is difficult to use.

A useful reservation states what is wrong, where the discrepancy lies, what evidence demonstrates it and what outcome is expected.

Acceptance protects delivery when it is prepared upstream.
It becomes a source of friction when it relies on implicit expectations.

Secure IT systems access throughout the engagement

IT systems access is often treated as a secondary topic.

Yet it is critical when managing an engagement with a non-EU freelancer.

Access granted too late blocks production.
Access that is too broad increases security risk.
Access that is not revoked creates a risk after the engagement ends.

Apply the principle of least privilege

The freelancer must have the access required to perform the service, but no more.

This means defining:

• the tools accessible;
• the environments concerned;
• the rights required;
• the data that may be viewed;
• authentication rules;
• restrictions linked to sensitive data;
• the request and approval process.

Access must be tied to the engagement, not to a logic of permanent internal integration.

Document the access granted

The IT services firm must keep a clear record of the access opened.

This traceability facilitates:

• internal audits;
• client checks;
• incident management;
• offboarding;
• reversibility;
• proof of the measures taken in the event of a dispute.

It is recommended to keep a simple register: tool, access level, opening date, validator, justification, review date and closing date.

Anticipate end-client constraints

Some end clients impose strict rules: VPN, MFA, managed workstations, geographical restrictions, bans on access to certain environments and enhanced logging.

These constraints must be known before the effective start of the engagement.

If they emerge afterwards, they can block the engagement or require delivery to be reorganised.

Manage incidents without improvising

An incident may concern a delay, a defective deliverable, unavailability, blocked access, a security flaw, a production error or a disagreement over scope.

The reflex should not be to look for someone to blame in an emergency.

The reflex should be to qualify the incident.

Qualify the impact before acting

For each incident, the IT services firm must document:

• what happened;
• the date it was identified;
• the impact on the schedule;
• the impact on the end client;
• the deliverables concerned;
• possible corrective actions;
• dependencies;
• the validations required.

This qualification helps avoid impulsive decisions.

It also makes it possible to activate the right contacts: technical lead, delivery manager, security, procurement, legal, insurer if necessary.

On liability, delay or defective deliverable matters, management must remain consistent with how to allocate liability and insurance within the chain.

Distinguish between anomaly, change and non-compliance

Not all difficulties are handled in the same way.

An anomaly concerns a technical or functional discrepancy compared with what was expected.

A change concerns a new request or an adjustment to the initial scope.

Non-compliance concerns a deliverable that does not meet the acceptance criteria or the planned commitments.

This distinction avoids making the freelancer bear requests that were not included or, conversely, treating as a change something that is an expected correction.

Prepare reversibility before you need it

Reversibility is often considered too late.

Yet it must be built in from the start of the engagement, especially when the freelancer works on code, architecture, scripts, data, critical workflows or technical documentation.

Organise handover continuously

Reversibility does not mean asking for a knowledge transfer in the last week.

It relies on continuous practices:

• documentation of technical choices;
• useful comments in the code;
• up-to-date architecture diagrams;
• deployment procedures;
• decision logs;
• a readable backlog;
• centralised access;
• a code repository controlled by the IT services firm or the client according to the agreed framework.

Each deliverable must be capable of being taken over by another contributor without depending exclusively on the freelancer’s memory.

Plan exit deliverables

The end of the engagement must include offboarding deliverables.

Depending on the context, this may include:

• final documentation;
• ticket status;
• open points;
• identified risks;
• handover recommendations;
• access inventory;
• items to delete or transfer;
• confirmation of data return or deletion according to the applicable rules.

This stage must be provided for in the operational scope.
Otherwise, it becomes a late request that is difficult to frame.

Complete offboarding without leaving operational debt

Offboarding is a delivery act.

It closes the service, secures access and enables the IT services firm to regain control without friction.

Close deliverables and validations

Before the effective end of the engagement, the IT services firm must verify:

• the deliverables submitted;
• open reservations;
• expected corrections;
• documents transmitted;
• tickets in progress;
• unresolved decisions;
• remaining dependencies;
• validations obtained.

Closure must be formalised, even briefly.

An end-of-engagement message can recall the deliverables submitted, the items validated, any reservations and the remaining actions.

Revoke IT systems access

Access revocation must be systematic.

It concerns:

• development tools;
• code repositories;
• project messaging tools;
• ticketing tools;
• cloud environments;
• VPNs;
• internal tools;
• document spaces;
• test accounts;
• secrets, keys and tokens.

Access must not remain active “just in case”.

If subsequent work is required, it must be reframed in a new scope or a formalised extension.

Capture lessons from the engagement

A well-closed engagement also generates learning.

The IT services firm can document:

• what worked well;
• friction points;
• access lead times;
• deliverable quality;
• the relevance of the activity report;
• the smoothness of acceptance;
• risks that emerged;
• improvements for future non-EU engagements.

This feedback helps make subsequent engagements more reliable.

Where StelarWork fits into this management

StelarWork acts as the French supplier of the IT services firm in the contractual chain.

The company contracts in its own name with the IT services firm, invoices the IT services firm, remunerates the non-EU freelancer and carries the compliance framework associated with the work. The objective is to enable the IT services firm to work with a tech freelancer based outside the EU without creating a supplier that is difficult for procurement to sign.

For day-to-day management, the IT services firm keeps its delivery reflexes: specification, activity report, acceptance, IT systems access, deliverable tracking, reversibility and offboarding.

StelarWork acts as a French supplier, contracting in its own name: the relationship remains a service engagement, managed through deliverables and purchase orders.

The right operational model is simple:
the IT services firm manages a service, with deliverables and validations, within a clear supplier framework.

FAQ

How do you manage an engagement with a non-EU freelancer without multiplying meetings?

The most effective approach is to structure the work around writing: complete tickets, acceptance criteria, documented decisions, a usable activity report and synchronous points limited to decisions. Time-zone differences become manageable when the freelancer can move forward without waiting for permanent oral validation.

Should the activity report track time or deliverables?

The activity report may document periods of work, but above all it must remain useful for managing the service: tasks completed, tickets handled, deliverables produced, blockers, dependencies and items awaiting validation. It must not become a micro-management tool comparable to internal employee monitoring.

How do you avoid disputes during acceptance?

Acceptance criteria must be defined from the start. Each reservation must be precise, documented and tied to an acceptance criterion. Acceptance based on implicit expectations creates friction; acceptance prepared upstream secures delivery.

What should be planned for the offboarding of a non-EU freelancer?

You need to close deliverables, document any reservations, organise handover, recover or confirm deletion of the necessary items, then revoke IT systems access. Offboarding must be planned as a normal stage of the engagement, not as a last-minute formality.

Disclaimer

This article provides general information on the operational management of an engagement with a non-EU freelancer. It does not constitute personalised legal, tax, social-security or insurance advice.

Every situation must be analysed in light of the applicable contracts, the real execution context, the IT services firm’s internal rules, the end client’s requirements and competent professional advice.

On tax or residence matters, the reality principle prevails: effective tax residence, real presence outside the EU, activity genuinely carried out remotely, absence of organised presence in France. A healthy configuration is based on coherent facts. A shell entity or fictitious residence is an abusive configuration to be avoided.