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

The FDE Prototype: Why a Week Matters

In enterprise sales, a slide deck is a promise. A prototype is proof. As a Forward Deployed Engineer, you are not building a startup MVP to find product-market fit. You are building a surgical instrument to unblock a $500K–$5M contract. The customer has a painful, specific, messy problem. They don't need a platform. They need a wedge.

Speed is your primary currency. A prototype delivered in a week signals technical credibility and operational tempo. A prototype delivered in a month signals that your core product can't handle the edge case. This playbook walks through the exact compression algorithm FDEs use to go from a chaotic discovery call to a live, authenticated, working prototype in five working days.

The FDE Prototype Constraint Triad:

Day 0: The Inbound Firehose – Triage Before You Touch Code

You just got off a call. The AE is excited. The customer's CTO described a vague, sprawling nightmare: "We need to extract data from our legacy ERP, cross-reference it with our Salesforce instance, and generate compliance reports, but the format is weird."

The Trap: Building a generic ingestion pipeline. The FDE Move: Finding the atomic unit of value.

The "Five Whys" of the FDE

Don't just ask what they want. Ask what happens if they don't get it. This reveals the pain tolerance and the actual deadline.

1. Why now? (Triggers: Audit deadline? New regulation? Boss's bonus tied to this?)
2. Why not manually? (Reveals scale. If it's 10 records, write a script and walk away. If it's 10,000, we have a project.)
3. Why hasn't internal IT solved it? (Reveals political landmines or technical constraints.)
4. Why is the current output wrong? (The specific error is your acceptance criteria.)
5. Why you? (Reveals what they think your product does vs. what it actually does.)

Output of Day 0: A single sentence problem statement. Not "integrate ERPs." Rather: "The compliance team spends 8 hours/week manually copying column 'B' from a green-screen terminal into a CSV because the terminal can't export headers."

Day 1: The Whiteboard Slicer – Scoping to the Atomic Problem

You have the atomic problem. Now you must surgically remove every other feature request. The customer will say, "While you're in there, could it also...?" The answer is always "No, but let's write that down for Phase 2."

The "Single User, Single Action" Rule

Your prototype should do one thing for one persona. If you are building a dashboard, it has one chart. If you are building an extraction pipeline, it handles one file type from one source.

Architecture of a Week-Long Prototype:

The stack is boring by design. FastAPI, Streamlit, and direct API calls. No Kubernetes. No message queues. If you need durable execution, use a SQLite database, not Kafka. The goal is to minimize the number of moving parts so that when (not if) the customer's VPN drops, you can debug it in 30 seconds.

Scoping a messy LLM feature? You need a parser that survives malformed input. See how we structure resilient extraction in the Invoice and Receipt Extractor That Turns PDFs into Structured JSON playbook.

Day 2: Infra Scaffolding – Boring Tech That Just Works

Day 2 is about authentication and connectivity. This is where 90% of prototypes die. The customer's environment is a fortress. You will not get a clean API key. You will get a VPN, a jump box, and a 2012-era SOAP endpoint.

The Connectivity Playbook

1. Outbound Only: Never ask for an inbound firewall rule. Use ngrok or cloudflared tunnel to expose your local dev server if you need webhooks. If the customer blocks these, use a simple polling loop.
2. Auth Sniper: Do not implement SSO in the prototype. Use a shared secret, a pre-generated API token, or basic auth over TLS. You can swap to OIDC after the deal is signed.
3. The "Hello World" of Data: Before processing 10,000 rows, hardcode the retrieval of 1 row. Prove connectivity end-to-end immediately.

# Day 2 Mentality: Fail fast on connectivity
import requests
try:
    resp = requests.get(
        "https://customer-vpn.internal/api/v1/items?limit=1",
        headers={"X-API-Key": os.environ["CUST_TOKEN"]},
        timeout=5
    )
    resp.raise_for_status()
except requests.exceptions.Timeout:
    print("VPN tunnel likely down – ping ops")
except requests.exceptions.HTTPError as e:
    print(f"Auth layer working, endpoint returned {e}")

If you are deploying this in a heavily regulated enterprise environment (finance, defense), the connectivity hurdles are even higher. The Deploying an LLM Feature at an Enterprise Customer: A Week-by-Week Case Study details the specific terraform and VPC peering patterns that unblock these.

Day 3: Core Logic – The 80% That Moves the Needle

Day 3 is the "build day." You have connectivity. You have a scoped problem. Now you write the 200 lines of Python that actually transform the data.

The FDE Stack for Logic:

• Transformation: Pandas (if structured) or Instructor (if unstructured LLM extraction).
• Interfaces: Streamlit for rapid UI; a simple REST endpoint for system-to-system.
• LLM Calls: Use a cheap, fast model (e.g., GPT-4o-mini or Claude Haiku) for classification and extraction. Do not fine-tune. Use few-shot prompting.

Handling "Messy" Data: The customer's "weird format" is usually a PDF where the text is an image, or a CSV with 47 columns but only 2 matter. Do not build a generic parser. Write a script that hardcodes the column positions or the regex specific to their document ID.

# Not elegant. Works.
def extract_compliance_notes(raw_text):
    # Customer's legacy system prints "NOTES:" before the block
    match = re.search(r'NOTES:(.*?)(?:PAGE|\Z)', raw_text, re.DOTALL)
    return match.group(1).strip()

If the problem requires reasoning over unstructured data (like a knowledge base), don't build a RAG pipeline from scratch. Use the patterns from the Notion Knowledge Assistant That Answers Questions from Your Workspace to embed and retrieve in minutes.

Day 4: Hardening & The 'Production-Proof' Lie

You have a working script. Now you must make it survive a demo. The customer's champion will click the wrong button. They will upload a 2GB file. They will disconnect their WiFi.

The Demo Crash Kit

1. The Loading Spinner: If an operation takes >1 second, add a spinner. A frozen UI is interpreted as a crash.
2. Graceful Failure: Wrap the core logic in a try/except that catches Exception and prints a human-readable error to the UI. "Error: Unable to parse row 452 (expected date, got 'N/A')" is infinitely better than a 500 error.
3. Input Validation: Restrict file uploads to .csv or .pdf. Reject anything else immediately.

The "Production-Proof" Paradox: Do not add a database migration strategy. Do not add unit tests for edge cases you haven't seen yet. An FDE prototype is "production-proof" not because it handles everything, but because it fails safely and does not corrupt data. It is a read-heavy, write-cautious tool.

If you need to run complex SQL queries as part of this logic, don't guess at the schema. Use the SQL Analyst Agent That Answers Questions Over Your Free Postgres Database technique to let the LLM write the safe, read-only queries for you.

Day 5: The Handoff – Demo, Docs, and the Next Step

Day 5 is not about tweaking CSS. It is about controlling the narrative.

The 15-Minute Demo Structure

1. Minute 0-2: Restate the atomic problem you solved. "You said you spent 8 hours on X. Watch this."
2. Minute 2-10: The "Happy Path." Run the exact file they gave you. Show it working flawlessly.
3. Minute 10-13: The "Resilience Path." Intentionally upload a malformed file. Show the graceful error message. This builds more trust than the happy path.
4. Minute 13-15: Next steps. "To scale this to the full department, we need to discuss bulk licensing and a dedicated read replica."

The One-Pager

Do not write a 20-page technical spec. Write a one-page PDF with:

• Architecture diagram (the simple one from Day 1).
• Assumptions (e.g., "Assumes network egress on port 443 is open").
• Limitations (e.g., "Handles only CSV; XLSX support requires 2 weeks of dev").
• Path to Production (e.g., "Swap sqlite for Postgres, add SSO").

Comp & Career Context: This ability to compress time-to-value directly maps to compensation. While a pure software engineer might be evaluated on system design elegance, an FDE's leverage (and on-target earnings, often $180K–$280K+ for senior roles) is tied to the volume of revenue unblocked. A week-long prototype that unblocks a seven-figure deal is the clearest signal of performance. It's also the best shield against burnout: solving a concrete problem in a week is energizing; building a vague platform for a month is draining. For more on maintaining this balance, read the On-Site vs Remote FDE: Travel Realities, Burnout, and Setting Boundaries guide.

Frequently Asked Questions

What if the customer demands a feature that breaks the 'single user' rule? Log it publicly. Create a shared doc called "Phase 2 – Nice to Haves." Every time they add to it, they feel heard. Every time you don't build it, the prototype stays on schedule.

How do I handle data that is actually too messy for regex? Use a multi-modal LLM. If the data is a scanned PDF, pass the image directly to GPT-4o or Claude and ask for structured JSON. The Invoice and Receipt Extractor playbook covers the exact prompt structure and retry logic.

Should I build the prototype in the customer's cloud environment or ours? Yours, always. Run it on a cloud VM you control or even your local machine tunneled out. You do not want to wait 3 weeks for their IT to provision an S3 bucket. Get the data out, process it, push results back.

What if the prototype fails? Good. A failed prototype that clearly identifies a data quality issue in Week 1 saves the customer from discovering it in Month 6 of an implementation. Frame the failure as "accelerated learning" and pivot.