From Messy Problem to Shipped Prototype: The FDE Weekly Workflow

The Forward Deployed Engineer (FDE) role collapses the distance between a messy enterprise problem and a shipped prototype. It’s not pure sales engineering, and it’s not a comfortable two-week sprint with a refined Jira backlog. The weekly cadence is aggressive by design: inherit ambiguity on Monday, demo working software on Friday.

This playbook walks a concrete, repeatable weekly workflow. You’ll see the exact decisions, tools, and trade-offs an FDE makes when a Fortune 500 logistics customer sends a panicked email about their “broken document routing.” We’ll move from that vague SOS to a prototype that extracts data from PDFs, routes it via a webhook, and stores it in a customer-hosted Postgres instance. No hype. Just the work.

Monday: The Inbox Ambush and Triage

Monday starts with a forwarded email thread. A logistics company, Acme Freight, has a shared inbox drowning in PDF bills of lading. Their current “solution” is a team of 12 people manually typing fields into an ERP. The subject line: “Can your platform read these PDFs and just… put the data where it goes?”

The account executive wants a yes-or-no answer by Tuesday. You need a prototype by Friday. Your first job is not to build. It’s to triage.

The 60-Minute Triage Framework

Before opening an IDE, you spend one hour on a structured scoping doc. The goal is to convert a vague wish into a falsifiable hypothesis.

The Scoping Template:

• Pain Statement: One sentence. (e.g., “Manual extraction of 8 key fields from 200 PDFs/day causes a 4-hour processing lag.”)
• Success Signal: What does the customer need to see on Friday to believe this is real? (e.g., “A webhook that receives a PDF, extracts fields with >90% accuracy on their sample set, and inserts a row into a test table.”)
• The Hard No: What are we explicitly not doing? (e.g., “No UI. No auth integration. No handling of handwritten scans.”)

Setting the Hard No is the most critical FDE survival skill. The customer asked for “just put the data where it goes,” which in their mind includes Active Directory SSO, a React dashboard, and SOC 2 compliance. You are building the thinnest vertical slice that proves the core value. You can see how we apply the same ruthless scoping logic to an LLM feature in a risk-averse enterprise environment in our case study on deploying at a risk-averse customer.

By noon, you reply to the thread with a one-pager confirming the scope. You ask for exactly two things: a zip file of 20 sample PDFs, and a connection string to a throwaway Postgres schema. No meetings. No endless requirements gathering.

Tuesday: Discovery Calls and the Art of Saying No

Tuesday is the day you defend the prototype’s boundaries. The customer inevitably replies with “just one more thing”—they want it to work on faxed documents from 1998, or they need it deployed inside a VPC with no outbound internet access.

The Technical Deep-Dive

You spend 90 minutes on a call with their lead architect. This isn’t a sales call; it’s a peer-to-peer engineering discussion. You’re probing for landmines:

1. Data Residency: Does the PDF data ever leave their VPC? If yes, you need an on-premise extraction model. If no, you can use a managed LLM.
2. Latency Budget: Is this real-time (webhook) or batch (cron)? The integration surface changes completely.
3. Protocol Constraints: Can they receive a webhook, or do you need to push to an S3 bucket they poll? This determines whether you use n8n or a raw Python script.

This discovery process mirrors the investigative work FDEs do when debugging customer environments without direct access. The principles of extracting signal from a black box are the same, as detailed in our playbook on debugging without environment access.

By end of day, you’ve locked the technical contract. You’ll use an n8n instance (yours, for the prototype) to receive the PDF via webhook, a Python script to call a document extraction LLM, and Postgres as the sink. The architecture looks like this:

Wednesday: Architecture on a Napkin (and an n8n Webhook)

Wednesday is about getting the skeleton working end-to-end with fake data. If data flows from curl to Postgres by lunch, the rest of the week is just hardening.

Step 1: The n8n Listener

You spin up n8n locally or on a $20 cloud VM. The first node is a simple Webhook trigger. You configure it to accept a POST with a JSON body containing a file_url or a base64-encoded PDF. You wire the output to a Python Function node.

Step 2: The Python Glue

The n8n Python node is where the integration logic lives. It’s not heavy business logic—it’s a translation layer. It takes the incoming payload, calls the LLM extraction endpoint, parses the JSON, and formats an INSERT statement. For a similar pattern of using n8n as the orchestration backbone with an LLM backend, check out how we built a Discord FAQ bot with n8n and Supabase.

# Skeleton of the n8n Python node
import requests
import psycopg2

def extract_fields(pdf_base64):
    # Stub: call your LLM endpoint
    response = requests.post("https://api.llm-provider.com/extract", json={
        "model": "gemini-1.5-flash",
        "document": pdf_base64,
        "fields": ["bill_of_lading_number", "consignee", "weight", "pieces"]
    })
    return response.json()

# In real workflow, items[0].json would hold the webhook payload
data = extract_fields(items[0].json["file_base64"])
conn = psycopg2.connect(os.getenv("PG_CONN_STR"))
cursor = conn.cursor()
cursor.execute("""INSERT INTO shipments (bl_number, consignee, weight, pieces) 
                   VALUES (%s, %s, %s, %s)""", 
                   (data["bill_of_lading_number"], data["consignee"], data["weight"], data["pieces"]))
conn.commit()
return {"status": "ok", "bl_number": data["bill_of_lading_number"]}

By 4 PM, you run curl -X POST http://your-n8n/webhook -d '{"file_base64": "..."}' and watch a row appear in the customer’s test Postgres table. The core value proposition—unstructured PDF in, structured row out—is proven.

Thursday: The Build Sprint – Wiring the Plumbing

Thursday is the most intense day. The skeleton works on your machine with a perfect PDF. Now it needs to survive the customer’s real-world PDFs, which are scanned, skewed, and occasionally upside down.

Error Handling as a Feature

In a product sprint, you might write a spec for error queues. In an FDE sprint, you write a try/except block that logs the raw PDF to a “dead letter” directory and returns a graceful failure to the webhook caller. You don’t build a retry UI; you build a safety net.

The Prompt Engineering Sub-Sprint

You spend two hours iterating on the extraction prompt. The out-of-the-box LLM misreads “Consignee” as “Consigner” on 10% of the scanned docs. You add few-shot examples to the prompt and a post-processing validation step that rejects rows with null mandatory fields. This is the unglamorous 20% of work that makes the 80% demo possible.

Tooling Checkpoint

Your local setup now mirrors a lightweight production stack:

• Orchestration: n8n (handles retries, webhook parsing)
• Compute: Python (preprocessing, validation)
• Inference: Gemini (or a local Ollama model if the customer requires air-gapped). For a deep dive on running powerful models in constrained environments, see our analysis of running an 80B Qwen model in 4.3GB RAM.
• Storage: Customer’s Postgres instance

Friday: The Demo, The Debrief, and The Handoff

Friday is not a workday; it’s a performance day. The morning is reserved for a dry run. You break the demo into three acts:

1. The Problem Recap: Show the original PDF and the manual entry spreadsheet. State the pain.
2. The Magic Moment: Drag a PDF into a folder (or curl the endpoint) and refresh a SQL query to show the new row.
3. The Honesty Slide: A single slide titled “What This Is Not.” It lists every limitation (no handwritten text, no SSO, no SLA). This builds more trust than any feature.

The Handoff Artifact

The most valuable thing you leave behind is not the code—it’s a one-page Architecture Decision Record (ADR). It documents:

• Why you chose n8n over a raw Express server (lower ops burden for the prototype).
• Why you chose a managed LLM over a fine-tuned model (speed of iteration).
• The estimated productionization path: containerize the Python logic, move the LLM call behind a customer-managed API gateway, add a message queue.

This ADR saves the customer’s internal team months of debate. It’s the FDE’s force multiplier.

The FDE Weekly Workflow FAQ

Q: Is the FDE role just a solutions engineer who codes? No. A solutions engineer typically demos the existing product. An FDE builds what the product doesn’t yet do to close a strategic deal or retain a critical account. The output is a working prototype, not a slide deck. The compensation reflects this: top FDE roles at leading AI labs command $350K–$500K+ total compensation, rivaling pure research engineering positions.

Q: What tools should I learn for this workflow? Start with a low-code orchestration layer (n8n or Temporal), Python for glue code, and a deep understanding of one cloud provider’s networking primitives. The hardest part is not the AI—it’s the enterprise integration surface (SAML, VPC peering, legacy protocols).

Q: How do I handle scope creep on a Friday demo? Use the “Yes, and…” technique. “Yes, we can add a React dashboard, and that’s a Phase 2 item we can scope next week after we validate the data extraction accuracy.” Never say no; defer with a concrete next step.

Q: Where can I see a full code example of this kind of workflow? The n8n + LLM pattern is powerful for rapid prototyping. While this article focused on document extraction, we’ve published a full walkthrough of a similar architecture for a different use case—building a SQL analyst agent over Postgres with Gemini—which demonstrates the same principles of natural language to structured data flow.

Q: What if the customer wants the prototype deployed in production next week? You don’t. You clearly label the artifact as “Prototype: Not for Production Use.” The ADR outlines the 6-8 weeks of work needed for hardening, security review, and scaling. FDEs accelerate the sales cycle; they don’t bypass engineering fundamentals.