Picture the same engineer in two customer meetings.
In the first, the customer explains a broken workflow, sets its security rules and agrees on acceptance criteria. The software company's engineering manager turns that input into technical priorities, assigns the work and reviews the engineer's performance.
In the second, the customer sets the engineer's daily backlog, requires fixed attendance, approves leave and gives the performance feedback that determines the person's future on the account.
The title, codebase and customer can be identical. The employment question is different.
An employer of record may be able to employ a locally based, work-authorized forward-deployed engineer when the EOR accepts the country, duties, work locations, domestic travel and supervision chain. The EOR should also confirm whether the disclosed customer-system and customer-site pattern changes its employment acceptance or coverage. The software company and end customer separately approve technical, data and site permissions. The strongest case keeps engineering direction and performance management with the hiring software company. The customer can define business requirements, control its systems and premises, and accept the contracted result.
If the customer will control the engineer's personal schedule, daily priorities or performance, disclose that arrangement before the offer. The local employment or agency route may need a different assessment, and the provider may accept, condition or decline the case.
Borderless's public material explains the ordinary EOR model, but it does not confirm acceptance of a forward-deployed engineer at an end customer's premises or inside its systems. The written case decision still matters.
This article assumes the selected engineer already lives and can work in the employment country. Customer visits remain within that country. Relocation, visas, work in another country, security clearances and managed technical delivery sit outside this scenario.
Give the provider a real assignment, not an FDE title
Forward-deployed engineering has no single work pattern. Palantir's current London posting combines customer relationships, custom production software and expected travel. Its Seoul posting describes direct customer collaboration, custom applications and client-site travel. These postings show two real versions of the role. They do not define every FDE or establish that an EOR accepts either version.
Start with a completed assignment record. This hypothetical gives each reviewer enough detail to find the open decisions:
The record should say how work will happen, even when the final answer is conditional. “Forward deployed” can hide the facts that control acceptance.
The customer can control the outcome without managing the engineer
Borderless's public EOR description places daily tasks, working from home, travel, expenses and performance expectations with the client company. Borderless handles the local employment contract and describes its role across payroll, tax, insurance, benefits, legal forms and employment administration.
For a forward-deployed engineer, that client company is the software company buying EOR service. The software company's customer is another party. Keep the two relationships visible.
A customer meeting, deadline, access rule or acceptance test does not by itself prove that the customer supervises the worker. The actual pattern matters. Ask who can change the engineer's schedule, assign tomorrow's tasks, approve time off, evaluate performance, move the person to another account or end the assignment.
Customer teams can raise incidents and request priority changes. The software-company manager should decide how those requests become personal assignments. If the customer bypasses that manager and directs the engineer in practice, describe the real pattern to the provider.
The distinction can affect the legal route. ILO Convention 181 defines one private-employment-agency service as employing workers to make them available to a user enterprise that assigns tasks and supervises their execution. National law and practice decide how that framework applies, which activities are permitted and how responsibilities are allocated.
That convention does not classify this engineer. It gives the buyer a precise fact to disclose. If the end customer will supervise execution rather than state the problem and accept the software company's result, ask the EOR and qualified local adviser whether the proposed route still fits.
Get a written decision on the exact role
Country coverage answers only the first part of the provider question. The provider still needs the assignment record, proposed employment package and customer-boundary map.
A current Deel workflow illustrates why. It validates the job scope, separately collects remote or on-site/hybrid work arrangements in applicable countries, and reviews on-site frequency before finalizing the quote. Deel also routes later work-arrangement changes through an amendment request. This is Deel's process. It does not establish a universal rule or Borderless capability.
Ask the proposed EOR to return one written case decision that states:
- the employing entity and local employment or agency route;
- the accepted duties, normal work location, customer-office frequency and domestic travel;
- the accepted supervision chain, including what the customer may and may not direct;
- whether the disclosed system and site pattern changes employment acceptance, coverage or insurance, while technical, data and site permissions remain with the company and customer;
- the employment terms, onboarding inputs and commercial dependencies required before the start;
- the facts that require reassessment, an amendment or a new route; and
- what the provider declines or leaves to the company, customer or specialist adviser.
A generic confirmation that the country is covered leaves the central capability question open. A useful answer accepts, conditionally accepts or declines the disclosed case.
Carry the accepted facts from the offer to customer work
Once the provider accepts the case, use the same assignment reference across the employment and customer workstreams. The documents have different jobs, so the shared facts need clear owners.
1. Freeze the accepted role and boundary
Give the record a version, such as FDE-CA-001-v1. Record the accepted duties, company manager, normal locations, travel pattern, customer-control limits, access assumptions, conditions and exclusions.
The EOR confirms the employment scope it will support. The software company confirms that managers and customer teams can operate within that scope. A hidden requirement to spend every day at the customer office or take direction from a customer manager means the record is incomplete.
2. Approve the EOR service and employment package
Review the EOR service terms, quote, responsibilities, notices and escalation path. Then settle salary, currency, working pattern, benefits, leave, expenses, equipment and the proposed start with their dependencies.
The broader EOR guide explains the general model. The contract guide owns the wider country-aware contract questions. This hire needs those principles applied to the accepted role rather than copied into a generic template.
3. Issue and complete the local employment documents
The legal employer should finalize the local employment documents through its approved process. The engineer supplies the required identity, address, work-permission, tax, banking and benefits information through the provider's secure route.
Borderless's current onboarding tracker says the company submits employment details and signs a Statement of Work, after which Borderless finalizes the employment agreement. It also distinguishes invitation status from complete employee onboarding and payroll readiness.
That Borderless Statement of Work governs the EOR service process. The software company's implementation statement of work or customer agreement is a separate contract. Neither document automatically grants the engineer access to customer systems or premises.
Borderless currently recommends adding an employee at least five business days before the proposed start, or ten business days when requesting customizations. Treat those figures as planning guidance after the case is accepted. They do not promise provider acceptance or a customer-access date.
4. Release the first customer assignment
The software company owns the delivery plan: named engineering manager, first backlog, code-review path, equipment, repositories, company security training and escalation contacts.
The end customer owns its release: named sponsor, approved accounts, permitted data, environment, site entry, security training and any customer-specific condition. The hiring company should also confirm that its customer agreement, confidentiality and rights chain cover the engineer's work. The EOR cannot promise the software result, waive the customer's controls or manufacture a missing clearance.
Use access with the smallest scope that supports the accepted first work. A later request for production credentials, regulated data, privileged administration or a different site returns to the relevant owners before access expands.
5. Confirm two dates and an interim plan
Record the employment start and first customer-work date separately. They may match. If customer access arrives later, give the engineer useful paid company work that fits the accepted role, such as product training, architecture review, test-environment setup or documentation.
Do not ask the engineer to start customer work while the employment arrangement, access or provider condition remains unfinished. A software account can be provisioned quickly and still be the wrong release point.
Keep the three organizations visible after day one
The operating map below preserves the public EOR split without assigning legal duties that depend on the country and contracts.
Local safety, insurance, data, contracting and employment duties still need case-specific verification. The table is a coordination record, not a transfer of responsibility.
Reassess when the customer boundary moves
One accepted assignment should not silently approve every later customer. Reopen the affected decision before any of these changes:
Proceed on a written match
Proceed toward the offer when the EOR confirms the local route and disclosed work, the software company retains an accepted management model, the employment terms match the locations and travel, and the first customer has approved the required systems or site access.
Hold or change the route when the provider cannot confirm the actual case, the customer expects to supervise the individual as its own labour, or the buyer needs a managed delivery team, mobility service or clearance that the proposed EOR arrangement does not supply.
For Borderless, send the assignment record through a case review and ask for role-specific confirmation. Public country coverage begins the review. The written answer to the real duties, direction and customer setting supports the hiring decision.