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

The Forward Deployed Engineer (FDE) operates in the messy intersection of enterprise sales, product gaps, and raw engineering. You aren't handed a clean Jira ticket. You are handed a 45-minute Gong recording, a 20-page PDF of vague requirements, and a Slack message from the Account Executive that just says: “Can we build something that auto-reconciles their ERP data? They are churning on Friday.”

Turning that chaos into a shipped prototype in a single week isn’t just a party trick; it’s the economic engine of the FDE role. It’s the difference between a $500k expansion deal closing and a churned logo.

This playbook breaks down the exact tactical workflow—sans hype—for compressing a messy enterprise problem into a demonstrable prototype in five working days.

The FDE Baseline: Chaos as a Service

Standard product engineering relies on refinement, grooming, and sprint planning. FDE engineering relies on signal extraction. The customer rarely knows what they want; they only know their current pain. Your first job is to ignore the proposed solution and map the underlying data flow.

Enterprise problems usually fall into three buckets:

1. The Hairball: Data trapped in a legacy system (SAP, mainframe, niche ERP) that needs to be bridged to a modern interface.
2. The Swiss Cheese: A process full of manual human review gaps that needs an automation layer.
3. The Translator: Format mismatch (e.g., EDI to JSON, PDF to structured SQL) that requires an intelligent parser.

If you can’t categorize the problem into one of these three buckets within the first 15 minutes of the call, you don’t have a prototype, you have a research project.

Day 0: Triage and the 'One Metric That Matters'

Before writing a single line of code, you must weaponize the scope. The biggest risk to a one-week prototype is the customer adding “just one more field.”

The Triage Playbook:

• Kill the UI (for now): The customer will ask for a beautiful dashboard. Push back. A Slack bot, a CSV email attachment, or a webhook is a valid prototype interface.
• Define the Timebox: Explicitly state: “I am building a single-threaded script that demonstrates the critical path. It will not be highly available. It will not handle multi-tenancy. It will prove the data can move.”
• Find the 'Wow' Moment: Identify the single manual task that takes the user 3 hours today. If your prototype reduces that to 30 seconds, you win.

Day 1-2: Hardcoding the Happy Path

Forget test-driven development. Forget abstractions. In week-one prototyping, duplication is better than the wrong abstraction.

The Stack Strategy: Use the stack you know, not the stack that’s “right.” For most FDEs, this is Python or TypeScript. The goal is to prove logic, not to scale.

Workflow Snapshot:

The Hardcoding Rule: Don't write a generic parser if the customer only has one file format. Don't build a dynamic schema mapper if the fields are static. Write a script that assumes the exact headers the customer gave you.

# Bad prototype code: over-engineered
# def parse_generic_csv(path): ...

# Good prototype code: brutally specific
def reconcile_invoice(filepath):
    df = pd.read_csv(filepath)
    # Hardcoded mapping to the customer's exact SAP fields
    payload = {
        "BUKRS": df.iloc[0]['Company Code'],
        "BELNR": df.iloc[0]['Invoice Number'],
        "WRBTR": float(df.iloc[0]['Amount'])
    }
    return payload

Day 3: Wiring the 'Ugly' Infrastructure

Day 3 is where prototypes usually die. The logic works on your laptop, but you need to show it running against the customer’s staging environment. This requires defensive infrastructure minimalism.

Tactical Environment Setup:

• Secrets: A .env file. Don’t bother with HashiCorp Vault yet.
• Hosting: A single DigitalOcean droplet, a Render web service, or an AWS Lambda function. If it requires Kubernetes, you’ve lost the plot.
• Scheduling: A cron job or a simple sleep loop in a container. Do not build a message queue (Kafka/SQS) unless the customer problem explicitly demands event streaming.

The Authentication Hurdle: Enterprise auth is the silent killer. If the customer uses a VPN, whitelist your IP. If they use OAuth, use a long-lived refresh token and hardcode it (in a secure .env variable, obviously). Do not build a full OAuth dance flow in week one.

Day 4: The Hard Pivot and Edge Cases

You will demo a rough version to the internal team (the AE and Solutions Architect) on Day 4 morning. This is the “flinch test.” They will immediately spot a critical assumption you made about the data that is wrong.

Expect these pivots:

• “They actually use two different formats for historical data.”
• “We can’t write to the API; we can only generate a file for manual upload.”
• “The IDs aren’t unique; we need to fuzzy-match on the description string.”

The Pivot Protocol: Don’t rewrite the core logic. Add a pre-processing shim.

# Shim to handle the 'two format' pivot
def normalize_input(source):
    if "legacy" in source:
        return parse_old_format(source)
    return parse_new_format(source)

If you need to add intelligence (fuzzy matching, categorization) that rules can’t handle, this is the moment to drop in a cheap LLM call. You can build a simple classification agent without training a custom model. For example, if you need to triage text-based issues, you can adapt patterns from building a GitHub Issue Triager to auto-label and route messy data entries.

Day 5: Polishing the Demo Narrative

A working script is not a shipped prototype. A shipped prototype has a narrative. The customer must see themselves in the demo.

The Demo Assembly:

1. Use their data: Never show a demo with "Lorem Ipsum" or generic "Acme Corp" data. Use the sample CSV they sent you on Monday.
2. The “Black Box” Trick: Hide the messy terminal logs. Wrap your script in a 20-line Streamlit app or a simple HTML form. Visual perception is 90% of the credibility.
3. The Failure Preview: Intentionally show what happens when bad data enters. “Here’s where we catch the duplicate invoice and alert the team.” This demonstrates you understand the messy reality, not just the happy path.

The Comp Context: Why Speed Pays

Why do FDEs subject themselves to this intensity? Because the compensation model is directly tied to product revenue influence.

• Base Salary Band: $150k - $220k+ at top-tier enterprise SaaS companies.
• Variable/EQUITY: FDEs often sit on a sales-comp accelerators or receive RSU grants that dwarf standard backend engineers. An FDE who consistently saves $1M+ logos in a quarter can see total comp (TC) north of $300k.
• Career Velocity: The role is the ultimate startup prep. You learn to build without a spec, sell without being a salesperson, and handle customer fire drills. It’s no coincidence that many FDEs transition to founders. If you’re interested in that trajectory, read more on why FDE is the ultimate startup prep.

FAQ

What are the 4 types of prototypes?

In the FDE context, we ignore academic classifications (paper, digital, etc.) and focus on utility: 1) Data Bridge (moving data from A to B), 2) Automation Script (replacing a manual step), 3) Interactive Mockup (UI with hardcoded backend), and 4) Algorithmic Proof-of-Concept (showing an AI/ML model works on specific customer data).

What is the major problem with prototyping?

The "prototype-production trap." The customer sees the working prototype and demands it be rolled into production immediately, ignoring the lack of monitoring, security, and error handling. The FDE must constantly communicate that the prototype is a visual contract, not a scalable product.

Can a prototype be a service?

Absolutely. A prototype doesn’t need a GUI. A Slack bot that listens for a command and returns a formatted report, or an automated email service that drops a CSV into a shared folder at 8 AM every day, is a valid and often superior prototype for enterprise workflows.

How to create a working prototype?

Follow the Day 0-5 playbook above: triage ruthlessly, hardcode the happy path with the customer's real data, use a lightweight wrapper (Streamlit/Slack) for the interface, and pivot based on the internal team’s feedback before the final customer demo. If you need a starting point for a common pattern, check out how to build a competitor monitoring agent for a concrete example of scoping a data-gathering prototype.