On-Site vs Remote FDE Work: Travel Realities, Client Expectations, and Lifestyle

The Forward Deployed Engineer (FDE) role is inherently physical. You aren't just writing code against an internal API; you are integrating with a legacy mainframe in a SCIF, debugging a robotic arm on a factory floor, or whiteboarding a data model in a classified conference room. Yet, the rise of remote-first infrastructure and LLM-assisted coding has fragmented the role. You can now find FDEs who haven't seen a client in person for six months, and others sleeping in Hilton hotels 4 nights a week.

This isn't a philosophical debate about "office culture." It's a logistical and economic calculation about where your body needs to be to unblock $10M in ARR. Let's break down the travel realities, client expectations, and lifestyle design of modern FDE work.

The FDE Location Spectrum: Not Just a Binary

Before weighing on-site against remote, we need to kill the binary. FDE work exists on a spectrum defined by deployment environment sensitivity and integration complexity.

• Embedded/Classified (100% On-Site): You are physically inside a government facility or a high-security enterprise. You use their air-gapped hardware. Travel is non-negotiable; you commute to a SCIF, not a WeWork.
• Industrial/Hardware (High-Touch On-Site): You are deploying computer vision models to manufacturing lines. You need to see the lighting conditions, the conveyor belt speed, and the physical safety mechanisms. You fly out for 2-week sprints, then retreat to write code.
• Enterprise SaaS (Hybrid Cadence): The classic Palantir-style model. You spend "Week 1" on-site building trust, mapping the data, and defining the UAT criteria. You spend "Weeks 2-4" remote, building the pipeline and the React dashboard. You return for the go-live.
• API-First/DevTools (Remote-First): You are integrating Stripe or Twilio. The customer's primary interface is your API documentation. Screen sharing and Slack Connect handle 90% of the work. Travel is reserved for quarterly business reviews (QBRs) or critical escalations.

The On-Site Reality: Travel Schedules and the 'Trust Tax'

If you choose the on-site path, you aren't just an engineer; you are a diplomat carrying a laptop. The primary currency you earn on-site isn't lines of code; it's situational awareness.

The Standard Travel Cadence: Most "heavy travel" FDE roles operate on a 3-1-1 or 4-1-1 rotation (Monday-Thursday on-site, Friday remote, or 3 weeks on, 1 week off). You are essentially a local hire with an expensive flight home.

The "Hallway Usability Test": The biggest advantage of on-site work is invisible to Jira. When you sit next to the client's data analyst, you see how they actually query the table. You notice they copy-paste a CSV into Excel every morning because they don't trust the API. You fix that in an hour. Remotely, you would have built the "correct" API integration and never realized the user was bypassing it entirely.

The Burnout Vector: On-site FDEs don't burn out from coding; they burn out from "context switching tax." You are performing emotional labor—calming an anxious VP, translating engineering constraints to business buyers—while also trying to ship a Python service in a noisy open-plan office. The travel itself is a physical tax. A 6 AM flight on Monday and a red-eye on Thursday destroys deep work capacity for roughly 48 hours a week.

The Client Expectation: When you are physically present, the client expects real-time answers. You cannot say "let me get back to you on Slack" when you are sitting in their conference room. You must have either deep technical mastery or the extreme confidence to say "I don't know, but I will have an answer by 4 PM" without losing credibility.

The Remote Reality: Async Deep Work and the 'Visibility Gap'

Remote FDE work solves the travel exhaustion but introduces the visibility gap. Your output is entirely defined by digital artifacts: pull requests, dashboards, and Notion docs. If you are shipping, you are invisible. If you are blocked, you look absent.

The Async Workflow: The remote FDE lives in Loom videos and detailed Linear tickets. You record a 5-minute demo of a prototype, send it to the client, and they reply 8 hours later with feedback. This cadence allows for incredible engineering depth. You can spend 4 uninterrupted hours optimizing a SQL query that would be impossible to write on a noisy trading floor.

The "Lonely Failure Mode": The biggest risk for remote FDEs is building the wrong thing perfectly. Without the ambient chatter of the client's office, you might miss that the priority has shifted. You deliver a flawless feature, only to find the client asked for it three weeks ago in a meeting you weren't invited to. To survive remotely, you must over-communicate and constantly verify alignment.

The Tooling Stack: Remote FDE work demands a different toolbelt. You need to simulate presence.

You build a "virtual presence" loop: A client drops a CSV into a shared bucket, an n8n webhook triggers a pipeline in your local env, generates a preview URL, and a Slack bot pings the client channel "New data processed, preview here: [link]." This mimics the immediacy of on-site collaboration without the flight.

Comp and Lifestyle Arbitrage: The Numbers

Let's talk money and lifestyle design, because the financial calculus is drastically different.

The "Miles Millionaire" Trap: On-site FDEs often rationalize the grind through status: "I'm a Delta Diamond, I have 2 million Amex points." But you are trading your biological prime for depreciating airline currency. The remote FDE who moves to a no-income-tax state and buys back 15 hours of commute time per week often builds more wealth (and a stronger open-source portfolio) than the road warrior.

The "3-Month Rule" in Practice: Many people ask about the "3-month rule" for work. In the FDE context, this is the inflection point where the trust battery drains. If you haven't visited a client in 3 months, the relationship becomes purely transactional. For high-touch enterprise deals, a hybrid model—visiting for the first 2 weeks of a project, then going remote—often yields the best balance. You front-load the trust, then back-load the execution. For a deeper look at how these embed dynamics play out, see our breakdown on How Palantir-Style FDEs Embed with Customers: Rituals, Artifacts, and Trust.

Tooling and Rituals for Hybrid Sanity

Whether you are on-site or remote, you need asynchronous alignment. These are the rituals that prevent the "I built the wrong thing" disaster.

The Daily Loom/Slack Standup: Don't just write "Working on auth." Record a 90-second screen share of the login flow. "Here's the loading state. Is this spinner acceptable?" This forces the client to engage with the artifact, not the abstract status.

The Shared Prototype Environment: Never build locally for 3 weeks and then reveal a finished product. Deploy a rough version to a staging URL on Day 2. The "ugly baby" prototype strategy—showing work you are slightly embarrassed by—is the fastest way to kill bad assumptions. This is the core skill of scaling yourself before a handoff, which we detail in Scaling Yourself: When an FDE Hands Off a Prototype to Core Engineering.

The Decision Log: On-site, decisions happen verbally. Remotely, they disappear into Zoom ether. Maintain a running "Decision Log" in Notion or Linear. After every call, post: "Decision: We are using batch processing, not streaming, because the source DB can't handle read replicas. @client agreed." This artifact is your insurance policy against scope creep.

FAQ: On-Site vs Remote FDE Work

Is it better to be fully remote or fully on site for my job?

In Forward Deployed Engineering, "fully" either way is usually suboptimal. Fully remote risks a visibility gap where you miss unspoken client needs. Fully on-site risks burnout and prevents the deep work required to solve hard integration problems. The optimal pattern for most enterprise FDEs is a high-touch on-site sprint (1-2 weeks) to map the problem and build trust, followed by a remote build phase (3-5 weeks) where you ship the code, capped by an on-site go-live. This rhythm is often what separates a generic consultant from a true FDE.

Is remote work dying in 2026?

Not for high-skill technical roles like the FDE. While generic remote customer success roles are being pulled back to offices, the FDE is too scarce and too technical to mandate a commute just for optics. However, the "digital nomad FDE" is a myth for most enterprise settings. Clients with sensitive data (finance, defense, health) are increasingly enforcing "remote, but within national borders" or "remote, but with quarterly on-site audits." The travel isn't dying; it's just becoming more intentional and clustered around specific milestones rather than a constant weekly grind.

What is the 3 month rule for work?

In the context of client-facing engineering, the 3-month rule refers to the maximum healthy gap between physical touchpoints with a key stakeholder. If you go beyond a quarter without a face-to-face interaction (an on-site visit, a working session, or even a dinner), the relationship reverts to a vendor-client dynamic rather than a partnership. Trust decays. You stop hearing about the "shadow IT" project that might kill your deployment. High-performing FDEs schedule travel not just for project kickoffs, but for renewal conversations and roadmap presentations specifically to reset this clock.

What three factors should you consider when working remotely?

1. Artifact Velocity over Status Updates: Don't tell a client you are "80% done." Send them a staging URL. Remote trust is built through tangible, clickable artifacts, not text updates.
2. Synchronous Over-Communication: You must explicitly log decisions that on-site teams absorb through osmosis. A shared "Decision Log" or an automated standup bot (like the one in our guide on Build a Daily Standup Bot That Collects Updates and Posts a Summary to Slack with n8n and Gemini) replaces the missing hallway chatter.
3. Boundary Design: Remote FDE work bleeds into all time zones. Without the hard stop of a flight or a hotel check-out, you must manufacture hard stops (a gym class, a dinner reservation) to prevent 14-hour days of context-switching.

Does remote work hurt productivity for FDEs?

It hurts alignment productivity but boosts execution productivity. A remote FDE can write more code per hour. An on-site FDE writes less code but ensures it is exactly the code the client needs. The highest-leverage FDEs use on-site time to define the "what" and "why" with extreme precision, then guard their remote time to execute the "how" with zero interruptions.