On-Site vs Remote FDE: Travel Realities, Embassy Rules, and Building Trust

The FDE Spectrum: It's Not Binary

Standard engineering advice frames work as a binary choice: remote or on-site. For a Forward Deployed Engineer, that framing breaks immediately. The role exists specifically because complex enterprise software doesn't sell itself—it requires someone who can sit in the customer's conference room, whiteboard the integration, and write code against their actual data.

The reality is a spectrum. On one end, you have FDEs embedded with defense or intelligence customers, working inside a SCIF five days a week. On the other, you have FDEs supporting a portfolio of mid-market accounts, flying in for quarterly on-sites and handling the rest async. Most live in the middle: heavy travel sprints followed by remote build weeks.

A common pattern: Monday morning flight out, Tuesday-Thursday on-site with the customer's engineering team, Friday flight home. The following week is remote—shipping the integrations you scoped, writing technical docs, and handling other accounts. This cadence isn't accidental. It's optimized for the reality that high-context, high-trust work happens in person, but shipping production code requires uninterrupted deep work that airplanes and conference rooms don't provide.

The Integration Death Spiral

Here's what happens when you try to do this fully remote. A large logistics company signs a contract. Their data lives in a legacy Oracle system behind a VPN that requires a physical token. Your first integration call: six of their engineers join from a conference room, you're on a laptop speaker. You can't see the whiteboard where they're drawing their data model. You ask for API docs—they don't exist. You ask for a sample CSV export—it'll take two weeks through their change management process.

Three weeks in, you've had eight hours of meetings and shipped zero lines of code that touch their actual environment. Trust is eroding. The champion who bought your software is getting nervous.

Now the on-site version. You fly in Monday. By Tuesday at 10 AM, you're physically plugged into their network, running SELECT * FROM shipments LIMIT 10 against the real database. You discover the status field has 47 distinct values, not the 5 their documentation claimed. You build the first working end-to-end pipeline by Thursday afternoon. The champion sees data flowing in your UI. Trust isn't built through slide decks—it's built through that moment.

The Travel Cadence: 75% Travel Is Real

Job postings that say "75% travel" aren't exaggerating. For enterprise FDE roles, that number is often a floor, not a ceiling, during a customer's initial deployment phase. Let's break down what that actually looks like month-to-month.

Month 1: Heavy On-Site. You're on the road three weeks out of four. Week 1 is discovery and network access. Week 2 is building the core integration against real data. Week 3 is user acceptance testing with the customer's frontline operators. You're living out of a carry-on, expensing dinners, and accumulating airline status at an alarming rate.

Month 2: Hybrid. The integration is live. You fly in for a 2-day working session to handle edge cases that emerged in production. The rest of the month is remote: monitoring, iterating on the pipeline, and starting discovery with your next account.

Month 3: Maintenance + Expansion. You're on-site maybe one week. The customer's own engineering team is now comfortable enough to handle routine issues. Your travel shifts to the next new logo.

This cadence is why FDE compensation packages are structured the way they are. The base salary is high, but the real story is in the travel perks and equity. More on that later. For now, internalize this: if you're interviewing for an FDE role and the recruiter says "some travel," ask for the exact percentage and the average trip duration. "Some" means different things at a Series B startup versus a defense contractor.

The Embassy Rules: SCIFs, Visas, and Air-Gaps

Not all on-site work is created equal. A subset of FDE roles—particularly in defense, intelligence, and government—operate under constraints that make standard remote work impossible, not just inconvenient.

The SCIF Reality

A Sensitive Compartmented Information Facility (SCIF) is a room designed to block electronic signals. No phones, no smartwatches, no laptops that haven't been approved. You code on a machine with no internet access. You can't Google an error message. You can't copy-paste from Stack Overflow. Your entire development environment must be pre-loaded, and your toolchain must work fully offline.

This sounds like a nightmare for a modern developer. For FDEs who thrive in this environment, it's a forcing function for deep competence. You learn to read source code instead of skimming blog posts. You build a personal knowledge base that doesn't depend on internet access. And you develop a reputation as someone who can operate in the most constrained environments—a reputation that commands a significant compensation premium.

Visa and Embassy Logistics

International FDE deployments add another layer. You're not just traveling to another office—you're embedding with a foreign government agency or a multinational's regional headquarters. This requires work visas, not tourist visas. The distinction matters: working on a tourist visa is illegal in most countries, and enterprise customers will require proof of proper authorization.

Practical realities:

• Visa processing times: 4-12 weeks for many countries. Your start date may depend on a consular officer's schedule.
• Equipment carnets: If you're bringing specialized hardware, you need an ATA Carnet to avoid paying import duties. Your ops team should handle this, but you need to know it exists.
• Embassy support: If you're deploying to a politically unstable region, your company should have a relationship with the local embassy and a evacuation plan. This is table stakes for serious enterprise FDE work.

Building Trust When You're Not in the Room

This is the core challenge of the remote portion of FDE work. When you're on-site, trust builds automatically through presence: you're visibly working hard, you're eating lunch with the team, you're solving problems in real-time. Remote trust requires deliberate engineering.

Artifact-Driven Communication

The most effective remote FDEs I've seen don't send status updates. They ship artifacts. An artifact is a concrete, standalone piece of value that the customer can interact with without you present.

Examples:

• A recorded Loom video walking through the integration architecture, with timestamps for each section
• A working Postman collection pre-loaded with their actual API endpoints and sample responses
• A decision log documenting every technical trade-off made during the on-site, with rationale

The rule: every synchronous meeting should produce an asynchronous artifact. If you spend 30 minutes on a call, you spend 10 minutes afterward packaging the outcome into something durable. This compounds. After a month, the customer has a library of resources they can reference and share internally. That library is trust, materialized.

This is the same discipline required to write customer-facing technical docs that engineers and execs actually read. The principles transfer directly.

The Async Prototype Cadence

Here's a concrete workflow for the remote weeks between on-site visits:

1. Monday AM: Ship a small, working prototype that addresses the top pain point from last week's on-site. Deploy it to a staging environment the customer can access.
2. Tuesday: Async review. Customer's engineers test it and leave comments in a shared document or Linear/Notion.
3. Wednesday: Incorporate feedback, ship v2.
4. Thursday: Record a 5-minute demo and post it in the shared Slack channel. Ask one specific question to prompt engagement.
5. Friday: Write a brief retrospective: what shipped, what's blocked, what's next. This is your "coming up for air" day.

This cadence mimics the tight feedback loops of on-site work. The customer sees forward progress every single day. That visibility is the antidote to the "are they actually working?" anxiety that kills remote consulting relationships.

Comp and Leverage: The On-Site Premium

Let's talk numbers. FDE roles that require heavy on-site presence or specialized clearances command a premium. The market acknowledges that living out of a suitcase and navigating SCIFs is harder than working from a home office.

These are 2025 numbers for senior-level FDEs at growth-stage companies. The spread widens at the staff/principal level. For a deeper dive into how these packages are structured and how to negotiate them, see the full breakdown of forward deployed engineer compensation in 2025.

The comp premium isn't charity. It's hazard pay for the lifestyle cost. On-site-heavy FDEs burn out faster. The companies that retain them do so by making the financial trade-off explicit and by building real support infrastructure: dedicated travel coordinators, mandatory "no-fly" weeks after heavy sprints, and clear paths to transition into remote-first roles as seniority increases.

FAQ: The Hard Questions

Is it better to work remotely or onsite?

For an FDE, "better" depends on the phase of deployment. On-site is better for discovery, trust-building, and navigating air-gapped environments. Remote is better for shipping production code, maintaining multiple accounts, and having a sustainable life. The best FDEs do both in a deliberate rhythm. Early-career FDEs should bias toward on-site to build the customer intuition that remote work requires.

Is remote work dying in 2026?

For FDE roles specifically: no, but it's bifurcating. Pure remote FDE roles are growing for SaaS products with modern APIs and cloud-native architectures where integration can be done without physical access. On-site-heavy roles remain strong in defense, hardware-adjacent software, and legacy enterprise modernization. The middle ground—the "fly in when needed" model—is becoming the default.

How to make $1000 a week remotely?

This question often comes from engineers exploring freelance or contract FDE-adjacent work. At standard FDE rates, $1000/week is roughly 10-15 hours of contract work. The path: build a specialization in a specific enterprise integration (e.g., SAP, Oracle, Salesforce), demonstrate the ability to ship without hand-holding, and charge a daily rate. The FDE skill set—shipping fast in messy environments—commands a premium in the freelance market. If you're building your own tooling to accelerate this kind of work, you might start with something like a job-application autofill browser extension using Groq and Playwright to automate the repetitive parts of your workflow.

What is the difference between on-site and remote?

Beyond the obvious location difference, the FDE-specific distinction is access and trust velocity. On-site gives you physical access to systems, real-time whiteboarding with the customer's best engineers, and the social bonding that makes difficult conversations easier. Remote gives you control over your time, the ability to work across multiple accounts, and the necessity to build systems (documentation, async demos) that scale. The best FDEs treat remote not as a perk but as a skill to be engineered.

What if I want to transition from pure remote to on-site FDE work?

Start by volunteering for the hardest on-site problems in your current company. Offer to fly out for the struggling account. Document what you learn. Build the pattern recognition for messy enterprise environments. The first on-site deployment is a leap of faith—for you and your employer. Make it small, make it successful, and use that win to negotiate for more. The playbook for that first deployment is exactly what we cover in from messy enterprise problem to shipped prototype in 5 days.