FDE Playbook: From Customer Chaos to Shipped Prototype in 5 Days

The Monday morning Slack ping isn’t a tidy Jira ticket. It’s a forwarded email chain with 47 replies, a vague PDF attachment, and a single line from the Account Executive: “Can we show them something by Friday?”

This is the Forward Deployed Engineer’s native environment. We don’t get greenfield repos and sprint planning. We get a messy enterprise problem—often a hairball of legacy APIs, regulatory constraints, and a customer who knows their pain but not the solution—and we turn it into a shipped, working prototype before the week ends.

This playbook is the exact workflow I’ve used across dozens of zero-to-one engagements. No theory. Just the triage heuristics, architecture decisions, and shipping tactics that separate a prototype that closes a deal from one that sits in a demos/ graveyard.

The Monday Morning Firehose

A typical Monday starts with a problem statement like this (real, sanitized):

“Global bank needs to automatically extract covenants from 2,000+ credit agreements (scanned PDFs, mixed quality), map them to an internal risk ontology, and flag discrepancies against their current portfolio. Their current manual process takes 3 weeks per deal. They want to see it work on 10 agreements by Friday.”

You have 5 days. One shot at the demo. No room for a 6-month ML roadmap.

The Universal FDE Inputs

Every engagement, regardless of vertical, boils down to three inputs:

The bank problem hits all three. Let’s walk through how an FDE attacks it.

The 24-Hour Triage: Finding the Atomic Wedge

The biggest mistake junior FDEs make is trying to solve the whole problem. You can’t. You need to find the atomic wedge—the smallest slice of functionality that, when demoed live, makes the customer lean forward and say “that’s exactly the hard part.”

The Triage Framework

I use a 3-question filter on every engagement:

1. What is the customer actually doing manually right now? (Not what they say they want. What are they clicking, typing, copying-pasting?)
2. Where does 80% of the time go? (Almost always a bottleneck of manual extraction or cross-referencing.)
3. What’s the “magic moment” that would make a VP say “I need this”? (Hint: it’s rarely a dashboard. It’s usually a single, high-leverage output.)

For the bank, the answers were:

• Manually: Paralegals open each PDF, Ctrl+F for “covenant,” copy-paste clauses into a spreadsheet, then cross-reference against a 200-row risk taxonomy.
• Bottleneck: The extraction and mapping. Not the review. Not the approval workflow.
• Magic moment: Show a clause highlighted in the PDF, the extracted text, and the matched risk category—side by side, in under 5 seconds.

Scoping the Prototype Boundary

With the wedge identified, I draw a hard boundary around the prototype:

Anything outside this box—user auth, database persistence, multi-tenancy, export to Excel—is explicitly descoped. I tell the customer: “We’re building a single-user tool that processes 10 documents. If this works, we’ll architect the production system together.” This isn’t a limitation; it’s a feature. It sets expectations and builds trust.

Architecture Without Astronauts: The Scaffolding Sprint

By Tuesday morning, I have the wedge, the boundary, and a clear demo narrative. Now I need to stand up a working skeleton in under 4 hours. This isn’t about clean code. It’s about proving the data flow end-to-end with the real, messy inputs.

Tool Selection: The FDE Default Stack

When speed is the only metric that matters, I reach for a battle-tested stack:

The Scaffolding Code Pattern

I write a single script that does the ugliest possible version of the full pipeline, just to confirm every component can talk:

# scaffold.py — The "does it even work?" script
from PIL import Image
import pytesseract
import instructor
from openai import OpenAI

# 1. OCR a single page
def ocr_page(pdf_path: str, page_num: int) -> str:
    # Ugly, hardcoded, but proves the pipeline
    images = convert_from_path(pdf_path, first_page=page_num, last_page=page_num)
    return pytesseract.image_to_string(images[0])

# 2. Extract covenants with structured output
client = instructor.from_openai(OpenAI())

class CovenantClause(BaseModel):
    clause_text: str
    covenant_type: str  # e.g., "financial", "affirmative", "negative"
    confidence: float

def extract_clauses(ocr_text: str) -> list[CovenantClause]:
    return client.chat.completions.create(
        model="gpt-4o",
        response_model=list[CovenantClause],
        messages=[{"role": "user", "content": f"Extract covenant clauses:\n{ocr_text}"}]
    )

# 3. Test on one document
if __name__ == "__main__":
    text = ocr_page("sample_credit_agreement.pdf", 1)
    clauses = extract_clauses(text)
    print(f"Found {len(clauses)} clauses: {clauses[0].covenant_type}")

This script is throwaway code. But it surfaces the real problems immediately: the OCR quality on scanned docs, the LLM’s tendency to hallucinate clause types, the latency of the full pipeline. I fix these in the scaffolding phase, not on Thursday night.

Days 3-4: The “Duct Tape and Magic” Implementation

With the skeleton proven, Wednesday and Thursday are a controlled sprint. The goal isn’t production quality; it’s demo resilience—the prototype must work reliably on the 10 documents the customer provided, even if it would break on document #11.

Handling the Messy Reality

Real enterprise data is always worse than you think. The bank’s PDFs had:

• Scanned pages at 150 DPI with coffee stains
• Tables that pytesseract rendered as gibberish
• Covenants embedded in 50-page documents with no consistent heading structure

Tactic 1: Pre-processing Over Post-processing

Don’t try to fix bad extraction with regex. Fix the input. For the bank, I wrote a quick pre-processor that:

• Used cv2 to increase contrast and deskew scanned pages
• Chunked documents into 3-page sliding windows with overlap
• Filtered chunks by keyword density (“covenant,” “shall,” “ratio”) before sending to the LLM

This reduced LLM calls by 70% and improved extraction accuracy from ~60% to >90% on the target documents.

Tactic 2: The “Human-in-the-Loop” UI Pattern

A prototype doesn’t need to be fully autonomous. It needs to look autonomous while giving you an escape hatch. In Streamlit, I built a side-by-side view:

[PDF Viewer with highlighted clause] | [Extracted Text] | [Matched Risk Category]
                                      | [Confidence: 0.94]  | [Override ▼]

The override dropdown was pre-populated with the top-3 embedding matches from the risk ontology. If the LLM got it wrong, I could silently correct it during the demo without breaking flow. The customer sees the AI working; I see the safety net.

The Mapping Engine: Embeddings + Rules

The risk ontology was a 200-row CSV with categories like “Financial Covenant – Debt/EBITDA Ratio.” Pure LLM classification was too slow and inconsistent. Instead:

1. I embedded every risk category using all-MiniLM-L6-v2 and stored them in a simple NumPy array (no vector DB needed for 200 rows).
2. The extracted clause was embedded and compared via cosine similarity.
3. A thin rules layer caught edge cases: if the clause contained “EBITDA” and “ratio,” it boosted the “Debt/EBITDA” category score.

This hybrid approach—embeddings for recall, rules for precision—is the FDE’s secret weapon. It’s fast, explainable, and requires zero training data. For a deeper dive on structured extraction patterns, check out Why DSLs Are the Missing Link for Production-Grade LLM Applications.

Day 5: The Demo That Sells Itself

Friday morning isn’t for building. It’s for hardening the demo path and preparing for the conversation that actually closes the deal.

The Demo Script

I never demo features. I demo workflows that mirror the customer’s current pain. For the bank:

1. “Here’s what you do today.” I show a screenshot of their paralegal’s manual process (which I captured during the Monday discovery call).
2. “Here’s the same workflow in the prototype.” I drag a PDF into the Streamlit UI. In under 10 seconds, clauses are highlighted, extracted, and mapped.
3. “Let’s try one of yours.” I ask them to send me a PDF in the meeting. This is the trust moment. It works, or I use the override to make it work. Either way, they see their document, not my curated sample.

The FDE’s Real Deliverable

The prototype isn’t the deliverable. The confidence to buy is. After the demo, I immediately shift to the production conversation:

“The prototype processes 10 documents in sequence. In production, we’d parallelize the OCR across 50 workers, add a human review queue for low-confidence extractions, and integrate directly with your document management system via their API. I’ve scoped this at roughly 6 weeks for a production pilot.”

This transitions the conversation from “cool demo” to “when can we start.” For a realistic look at what a full FDE week looks like beyond the prototype, see What a Forward Deployed Engineer Actually Ships in a 60-Hour Week at an AI Startup.

The FDE Comp Reality Check

Why do FDEs tolerate the chaos? Because the comp reflects the direct revenue impact. A prototype that closes a $500K ACV deal is unambiguously attributable. Here’s the 2025 market reality for FDEs at growth-stage AI companies:

Note: Equity value is highly dependent on company stage and valuation. Ranges assume Series B–D companies with $200M–$2B valuations.

The key differentiator from pure SWE roles: FDE comp is heavily weighted toward bonus structures tied to customer outcomes (closed deals, expansion revenue). For a full breakdown of negotiation tactics and equity structures, read The FDE Compensation Reality: Salary Bands, Equity Structures, and Negotiation Tactics.

FAQ: The FDE Prototype Playbook

Q: How do you handle a customer who insists on seeing a production-grade UI in the prototype?

A: You don’t build one. You frame the prototype as a “functional specification.” Tell them: “I’m going to show you the engine working on your data. The UI is a wrapper—we’ll design that together once the core logic is proven.” Streamlit’s default styling is actually an advantage here; it signals “this is a prototype” and prevents the conversation from derailing into font choices.

Q: What if the LLM hallucinates during the demo?

A: This is why the human-in-the-loop pattern is non-negotiable. Every LLM output in my prototypes has a confidence score and a manual override. If the extraction is wrong, I say “the model is uncertain here—watch how easily a human reviewer can correct this” and use the override. The narrative shifts from “AI is unreliable” to “AI accelerates human review.”

Q: How do you choose between building a prototype and saying “this isn’t feasible”?

A: The triage framework answers this. If I can’t define an atomic wedge—a single, high-value interaction that can be demoed in under 30 seconds—the problem is likely too broad for a 5-day prototype. I’ll instead propose a 2-week paid discovery engagement to scope the solution properly.

Q: Do I need to be a full-stack engineer to be an FDE?

A: You need to be stack-agnostic. The core skill isn’t React or Kubernetes; it’s the ability to pick the right abstraction level for the problem. Sometimes that’s a Streamlit script. Sometimes it’s a custom DSL. The best FDEs I know can write Python, read Java, debug a REST API with curl, and explain a transformer to a CFO. Breadth over depth.

Q: How do I practice this workflow before my first FDE role?

A: The best training ground is building small, end-to-end automation projects on real-world messy data. Start with a problem from your own life—extract action items from meeting transcripts, classify your email receipts, build a Slack digest bot that summarizes channels every morning. The key is practicing the full pipeline from unstructured input to structured output, on a tight timeline. FDE Coach’s project-based curriculum is built exactly for this: shipping working prototypes against real constraints, not toy datasets.