From Messy Customer Problem to Shipped Prototype in a Week: An FDE Playbook

The Monday Morning Discovery: Triage and Scoping

Your Slack pings at 8:03 AM. An account executive at a logistics company has a customer threatening to churn. The customer’s problem: their dispatchers spend 4 hours a day manually cross-referencing PDF delivery confirmations against a legacy TMS (Transportation Management System) that only accepts CSV uploads. They want “AI automation.” The AE promises you can fix this in a week.

This is the raw material of forward deployed engineering. If you’re asking what does a forward deployed engineer do, this is the core loop: land in a messy, under-defined problem, decompose it into engineering constraints, and ship a working prototype before the urgency fades. It’s not consulting (you write production-bound code) and it’s not pure product engineering (you own the discovery, not a PRD).

The Monday playbook:

1. The 90-minute customer call. You don’t ask “what do you want?” You ask: “Show me your screen. Walk me through the last 5 deliveries you processed.” You watch them toggle between a web portal, a desktop folder full of PDFs, and an Excel sheet they use as a staging area. You take screenshots of every field they touch.
2. Define the success metric. You pin the AE down: “Churn risk drops if we cut processing time from 4 hours to under 30 minutes per dispatcher. That’s our success gate for Friday.”
3. Scope the prototype boundary. You’re not rebuilding their TMS. You’re building a thin bridge: PDF ingestion → structured data extraction → CSV output formatted for their TMS import schema. You explicitly list what’s out of scope: multi-page PDFs with tables, handwritten signatures, integration with their ERP.
4. Technical spike. By 5 PM you’ve run 3 test PDFs through a vision-language model to see if extraction quality is viable. You’re not building yet; you’re derisking the hardest assumption.

Tuesday: Architecture as a Constraint Solver

By Tuesday morning, you know the data shape. The PDFs are structured delivery confirmations with consistent field labels: "Customer PO," "Delivery Date," "Signed By." The legacy TMS expects a CSV with exactly 12 columns, including a "Status" enum that must match one of 4 values.

What does a forward deployed engineer do differently here? A product engineer might design a scalable microservice. An FDE designs the simplest system that survives the customer’s environment. That means:

• No new infrastructure. The customer’s IT team won’t approve a new cloud service in a week. You build a Python script that runs on a dispatcher’s existing Windows machine, triggered by a watched folder.
• Model selection is cost-aware. You test Gemini 1.5 Flash (free tier) against GPT-4o-mini. Flash gives acceptable accuracy on these structured PDFs and costs zero. You’re not optimizing for state-of-the-art; you’re optimizing for “works on Friday and costs nothing to pilot.” For a deeper dive on vision model extraction, see Convert Screenshots to Frontend Code with Gemini 1.5 Flash Free Vision Model.
• Error handling as UX. When extraction confidence is below 80% on a field, the script doesn’t fail silently. It pops a simple Tkinter dialog showing the PDF snippet and asking the dispatcher to confirm. You’re building a human-in-the-loop system from day one.

Tuesday deliverables:

• A 1-page architecture decision record (ADR) with 3 decisions, each justified in 2 sentences.
• A working extraction pipeline for a single happy-path PDF.
• A CSV output that passes the TMS import validator.

Wednesday: Build the Dirty Prototype

Wednesday is a heads-down build day. You’re writing code that would make a purist wince, and that’s the point. The prototype’s job is to validate the workflow, not to be beautiful.

The stack:

You’re not building a web app. The dispatcher’s workflow is: drop a PDF in a folder → script runs → if uncertain, a dialog appears → CSV lands in an output folder → dispatcher uploads to TMS. That’s it. The entire prototype is under 400 lines of Python.

The prompt engineering matters. You spend 2 hours iterating on the Gemini prompt to handle edge cases: PDFs where “Delivery Date” is sometimes labeled “Deliv. Date” or “Date Delivered.” You add few-shot examples directly in the system prompt. This is the kind of tactical LLM work that defines modern FDE execution. For another example of prompt-driven extraction in a customer workflow, see Build a Personal Meeting Notetaker Using Open-Source Whisper and Gemini Free Tier.

Thursday: The Customer Reality Check

Thursday at 10 AM, you’re on a video call with the dispatcher who will actually use this. You share your screen, drop a PDF into the watched folder, and… nothing happens. Poppler isn’t on their machine.

This is why FDEs ship prototypes to real environments, not staging. You spend 45 minutes debugging PATH variables over a remote desktop session. You learn their machine runs Windows 10 Enterprise with group policies that block unsigned executables. You switch to a pure Python PDF parsing fallback (PyPDF2 for text extraction, falling back to Gemini for image-based PDFs).

The dispatcher’s feedback is gold:

• “Can it handle when the driver writes the PO number in the margin instead of the field?” (No, not yet — you document this as a V2 requirement.)
• “The dialog box blocks my other work. Can it batch process?” (You add a queue mode in 20 minutes.)
• “Our TMS actually needs the file named IMPORT_YYYYMMDD_HHMM.csv or it rejects.” (You fix the filename template in 5 minutes.)

By 4 PM, the dispatcher processes 12 real PDFs from the previous day. Total time: 22 minutes, including 3 manual confirmations. You’ve hit the success metric. This is what a forward deployed engineer’s week looks like in practice — not building a perfect system, but closing the loop with the actual user fast enough to matter. For more on the tactical reality of an FDE’s week, see What a Forward Deployed Engineer Actually Does in a Week: Tactical Execution Reality.

Friday: Ship the Prototype, Write the Memo

Friday morning you package the script with a README.md that a non-technical dispatcher can follow. You use pyinstaller to create a single .exe (after getting IT to whitelist it). You write a 2-page internal memo for your engineering team that covers:

1. What we built and why (the thin bridge, not a platform)
2. Customer feedback and usage data (12 PDFs, 22 minutes, 3 overrides)
3. Productionization risks (the Poppler dependency, the free-tier API rate limit, the Tkinter UI won’t scale)
4. Recommended next step (a 2-week pilot with 3 dispatchers, then a decision on whether to productize)

The FDE’s Friday artifact is not just code — it’s a decision document. The prototype proves the workflow works. The memo tells the product team whether to invest. This dual deliverable is core to the role. If you’re preparing for this kind of work, the decomposition and communication skills are exactly what the interview process tests. See The FDE Interview Loop: Decomposition, Strategy, and Execution Without Leetcode Drills for a breakdown.

By 3 PM, the AE confirms the customer agreed to a 30-day pilot starting Monday. You push the code to a private repo, archive the memo, and your week is done. You didn’t build a product. You built a proof that a product should exist.

Comp and Career Context

If you’re researching what does a forward deployed engineer do with salary in mind, here’s the market reality as of mid-2025:

These numbers reflect roles at companies with established FDE programs (Palantir, Scale AI, Databricks, and a growing set of AI-native startups). The premium over pure software engineering comes from the revenue proximity — you’re directly tied to customer retention and expansion revenue. For a deeper look at how this plays out in the Palantir operating model, see How Palantir-Style FDEs Embed with Customers: The Delta and Echo Operating Model.

Is a forward-deployed engineer worth it? For companies selling complex technical products into enterprises, yes. An FDE converts a $200K contract at risk of churn into a $1M expansion by proving the product works in the customer’s environment. The ROI math is straightforward: if an FDE costs $250K fully loaded and saves or expands 2-3 enterprise deals per year, they’re a 5-10x multiplier.

Are forward-deployed engineers real engineers? Yes. The code ships to production or production-adjacent environments. The difference is scope: an FDE’s code is intentionally scoped to a specific customer’s problem, not a generalized platform feature. The engineering rigor is the same; the context is narrower and faster.

FAQ

How much do FDEs get paid? Entry-level FDE roles typically range $130K–$170K total comp. Mid-level (3-5 years) ranges $180K–$240K. Senior FDEs can reach $250K–$350K+, especially with deal-based incentives. The premium over standard SWE roles reflects the revenue impact and customer-facing skill requirement.

Is a forward-deployed engineer worth it? For enterprise SaaS and AI companies, FDEs are a high-ROI investment. They directly prevent churn, accelerate time-to-value for new customers, and generate expansion revenue by proving product value in the customer’s environment. One FDE can influence millions in annual contract value.

What is the average salary of a forward-deployed engineer? Based on current market data, the average total compensation across all levels is approximately $200K–$220K, with significant variance based on company stage, equity structure, and deal-based bonus programs.

Are forward-deployed engineers real engineers? Yes. FDEs write production-bound code, design systems, debug in real environments, and make architecture decisions. The distinction is that their code solves a specific customer’s problem on an accelerated timeline rather than building generalized platform features. The engineering discipline is identical; the scope and tempo differ.