How FDEs Turn a Messy Customer Problem Into a Shipped Prototype in a Week

It’s Monday, 9:07 AM. A Slack message from your Sales Director lands: “Acme Corp is churning unless we show them a working integration with their legacy ERP by Friday. Can we do it?”

There is no spec. The API docs are a 200-page PDF from 2008. The internal champion on the customer side is a VP of Operations who “doesn’t do technical.” This is not a bug fix. This is not a feature request. This is a Forward Deployed Engineer’s primary environment: high ambiguity, high stakes, zero room for academic purity.

The forward deployed engineer workflow is fundamentally different from product engineering. You are not building for a million users. You are building for one account’s immediate pain, and your prototype is a proof-of-value that unblocks a seven-figure contract. Here is the concrete, day-by-day playbook for turning that messy Monday message into a shipped prototype by Friday afternoon.

Day 0: The Inbound Firehose and Scoping Under Uncertainty

Before you write a single line of code, you must de-risk the problem. The biggest failure mode for FDEs is building the “perfect” solution to the wrong problem. You have roughly four hours to turn the vague ask into a minimal, testable hypothesis.

The 3-Question Scoping Framework

During your first call with the customer’s VP of Operations, ignore feature requests. Focus entirely on the current manual workflow and the specific moment of pain. We use a variant of the SPIN selling framework adapted for engineering:

1. Situation: “Walk me through exactly what happens today when you receive a purchase order from a supplier.”
2. Problem: “Where does it hurt the most? Is it the manual re-keying, the latency, or the error rate?”
3. Implication: “If we don’t solve this by next quarter, what does that cost you in overtime or missed shipments?”

The answer usually reveals a narrow bottleneck. In our ERP example, the VP reveals they have a temp worker manually typing PDF POs into a green-screen terminal for 20 hours a week. The prototype doesn’t need to automate the entire supply chain. It just needs to parse a PDF and POST a JSON payload to a specific endpoint.

The “Human-in-the-Loop” Constraint

Enterprise prototypes rarely ship fully autonomous logic on day one. They ship a UI that allows a human to verify the AI’s output before it hits the system of record. Explicitly agreeing on a “human in the loop” step reduces the accuracy requirement from 99.9% to 80%. That is the difference between a 2-day build and a 2-month build. Frame it as a feature: “We’ll build a review screen so your team stays in control.”

Day 1: The Architecture Draft on a Whiteboard (and the Trust Deposit)

Day 1 morning is for a synchronous, screen-shared whiteboarding session (Excalidraw, tldraw, or Miro). Do not go dark and build. The customer needs to see your thinking to trust you. This is a core tenet of the forward deployed engineer workflow: the process is the product.

The “Boring” Architecture

Your architecture must prioritize simplicity and observability. A typical prototype for the ERP parsing problem looks like this:

This stack is intentionally unsexy: Streamlit for the UI, Supabase for the audit log, and a hosted LLM (Gemini Flash) for extraction because it handles crappy scans better than traditional OCR. You are not building a microservice mesh. You are building a linear pipeline that fails loudly.

The Trust Deposit

During this whiteboarding session, point out exactly where things can break. “If the PDF is handwritten, the AI might hallucinate the total. That’s why we have this review screen.” This transparency is counterintuitive. Product engineers often hide edge cases; FDEs expose them to prove competence. This is covered in depth in our guide on How FDEs Build Trust with Non-Technical Stakeholders in Enterprise Deals.

Day 2-3: Building the Happy Path with a “Boring” Stack

You now have 48 hours to build the core pipeline. Resist the urge to configure a complex local dev environment. The forward deployed engineer tech stack prioritizes managed services and serverless functions to eliminate DevOps overhead.

The Stack in Practice

The “Happy Path” Pattern

Do not handle errors yet. Write a 50-line Python script that takes a hardcoded sample PDF, sends it to the LLM, and prints the JSON. Only after the extraction works perfectly on one file do you wrap it in a FastAPI endpoint.

# fde_extract.py - Day 2 Happy Path
import google.generativeai as genai
from pydantic import BaseModel

class PurchaseOrder(BaseModel):
    po_number: str
    supplier: str
    line_items: list[dict]
    total: float

def extract_po(pdf_bytes: bytes) -> PurchaseOrder:
    model = genai.GenerativeModel('gemini-2.5-flash')
    prompt = "Extract the purchase order data. Return valid JSON only."
    response = model.generate_content([prompt, pdf_bytes])
    return PurchaseOrder.model_validate_json(response.text)

This script is the prototype. Everything else (the UI, the webhook, the audit log) is scaffolding to get this function into the user’s hands.

Day 4: The Hardening Sprint and the “Demo Reset”

Day 4 is the most psychologically critical day in the forward deployed engineer workflow. You have a working happy path. Now you must intentionally break it before the customer does.

The 3-Hour Hardening Checklist

1. The Empty State: What does the UI look like before any PDFs are processed? (Don’t ship a blank white screen.)
2. The Poison File: Upload a corrupted PDF, a scanned handwritten note, and a file that is just a picture of a cat. Does the pipeline fail gracefully with a human-readable error, or does it throw a 500?
3. The Reset Button: Can the user easily delete a bad extraction and re-process it? In Streamlit, a st.button("Reprocess") that clears the session state is worth more than a perfect ML model.

The “Demo Reset”

Never show up to a Friday demo with a cluttered database full of your test runs. Write a script that truncates the relevant tables and seeds exactly two realistic demo scenarios. The first demo follows the happy path perfectly. The second demo shows the system catching an edge case and asking for human review. This narrative control is what separates a Forward Deployed Engineer from a backend developer. You are directing an experience, not just presenting code. For more on the non-coding skills that make this work, see our breakdown of the FDE Interview Loop.

Day 5: The Ship, the Handoff, and the Comp Conversation

Friday morning. You deploy the Streamlit app to Railway, connect the environment variables, and send the URL to the customer. The demo takes 20 minutes. The VP of Operations watches the temp worker’s 20-hour task happen in 90 seconds. The technical close is almost automatic.

The Handoff Artifact

Immediately after the demo, drop a one-page PDF (generated by the same LLM you used for extraction) into the Slack channel. This document must contain:

• The architecture diagram.
• The known limitations (e.g., “Struggles with multi-page tables”).
• The estimated path to production (e.g., “Replace Streamlit with React, add SSO”).

This artifact is the CTO’s ammunition to sell the deal internally. You’ve done their homework for them.

The Career Context

This week of work directly maps to compensation. Forward Deployed Engineer salary bands are tightly coupled to quota impact. While a product engineer might ship a feature that increases DAU by 0.1%, an FDE can point to a specific $500K contract that was saved or expanded because of their prototype. This linear attribution is why top FDEs at companies like Palantir or OpenAI command $200K–$350K+ total compensation. The skills required are not just technical depth but the ability to manage a room, scope under pressure, and write code that is “good enough” to prove value today.

If you want to practice the technical patterns required to ship at this speed, building side projects that connect AI to real data sources is the most effective training. For example, a project like building a personalized newsletter agent that curates RSS feeds with Groq and Supabase forces you to confront the same messy ingestion and parsing challenges you’ll face in the field, without the enterprise pressure.

FAQ: Forward Deployed Engineer Workflow

What is the difference between an FDE and a Solutions Architect? Solutions Architects draw diagrams and write SOWs. FDEs write code. The forward deployed engineering meaning is rooted in implementation. You are measured by shipped prototypes, not slide decks.

What is the most critical forward deployed engineer skill required for the one-week prototype? Ruthless scoping. The ability to say “we are not solving that this week” without damaging the relationship is the single skill that prevents burnout and missed deadlines.

How does the forward deployed engineer tech stack differ from a standard startup stack? FDEs prioritize tools with visual debugging (n8n, Streamlit) and managed auth (Supabase, Auth0) because they often operate without a dedicated frontend or DevOps team. The stack must be hand-off-able to a less technical customer or partner engineer.

Is the forward deployed AI engineer workflow different? The core loop is identical, but the scoping phase now includes an “LLM feasibility” check on Day 0. You spend 30 minutes testing a prompt on the customer’s actual data before committing to a timeline. This prevents promising magic that the model can’t deliver.

How do I get better at this without being an FDE? Replicate the conditions. Find a local business with a manual data entry problem. Offer to solve it for free in one week using a Python script and a simple UI. The constraint of a real user and a hard deadline teaches more than any course. If you want structured guidance on the learning path, FDE Coach provides frameworks specifically designed to accelerate this exact skillset.