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

Most software engineers optimize for scale. Forward Deployed Engineers (FDEs) optimize for time to signal. You aren’t building a platform for a million users. You’re building a prototype for a single enterprise customer who has a burning operational pain and a contract renewal coming up in three months.

The forward deployed engineer workflow is a race: you have roughly one week to turn a vague, often emotional customer complaint (“Our compliance reviews take two weeks and we’re losing deals”) into a working prototype that runs on their actual data. This isn’t a hackathon demo with mock data. It has to work in their environment, with their weird CSV exports, their SSO, and their security team watching.

Here’s the concrete, day-by-day playbook. No theory. Just the decisions, the tools, and the moments where you earn your comp.

Day 0: The Scoping Call – Isolate the Atomic Workflow

The customer says: “We need an AI-powered contract review tool that flags non-standard clauses and suggests fallback language based on our playbook.”

That’s a 6-month product roadmap. You have 5 days. Your job on the scoping call is to apply a surgical reduction until you find the atomic workflow: the smallest sequence of steps that, if automated, delivers 80% of the perceived value.

You ask:

• “Who touches the contract first?” – It’s a junior paralegal.
• “What’s the first thing they do?” – They open a Word document and manually highlight clauses that deviate from a 40-page PDF playbook.
• “How long does that highlighting take?” – 4 hours per contract.

There’s your atomic workflow. You aren’t building a full contract review tool. You’re building a prototype that takes a .docx file and a PDF playbook, and returns the .docx with the non-standard clauses highlighted. That’s it. No redlining. No fallback language generation. No Slack notifications.

The FDE rule: If you can’t describe the prototype’s single core action in one sentence without using the word “and,” your scope is too large.

You also extract the success criteria on this call. Don’t accept “the prototype works.” Ask: “If we put this in front of a paralegal on Friday at 2 PM, what does she need to see to say ‘I want this tomorrow’?” The answer is usually visceral: “She sees her own contract with the weird clauses already highlighted in yellow, and the highlights match what she would have done manually.”

This scoping discipline is the highest-leverage skill in the forward deployed engineer workflow. It prevents you from building a beautiful, over-engineered solution that solves a problem the customer doesn’t actually have. For a deeper dive on the non-technical side of this, see The Highest-Leverage Skills for an FDE in the AI Era Beyond Prompting.

Day 1: Architecture on a Napkin – Choose Boring Tech

You leave the scoping call with a clear atomic workflow. Now you need an architecture that can be built by one person in two days. This is not the time for a new database you’ve been wanting to try.

Here’s the stack decision tree most FDEs run in their head:

The architecture for the contract review prototype is brutally simple. Here’s the flow:

No message queue. No microservices. A single Python script with a python-docx library, a chunking function, a ChromaDB instance (ephemeral, in-memory) to store the playbook embeddings, and an OpenAI API call per clause. The whole thing runs in a single process.

The FDE rule: The prototype should run on your laptop from a single main.py file. If you need Docker Compose, you’ve over-engineered it.

Day 2-3: Build the “Golden Path” – Ignore Edge Cases

These two days are a focused coding sprint. But “focused” doesn’t mean “fast.” It means you are ruthlessly ignoring everything that isn’t the golden path.

The golden path for the contract reviewer:

1. User uploads a standard .docx contract (not a scanned PDF, not a Google Doc link).
2. The script parses it, finds numbered clauses.
3. Each clause is embedded and compared against the playbook.
4. The LLM returns a JSON array of {clause_number, is_deviated, explanation}.
5. The script uses python-docx to apply yellow highlighting to deviated clauses.
6. The modified file is returned.

What you are not building:

• Handling scanned PDFs with OCR. (That’s a separate atomic workflow for Week 2.)
• Handling tables or images in the contract.
• A retry queue for API failures. (Just fail and tell the user to try again.)
• A beautiful UI. Streamlit gives you a file uploader and a download button in 4 lines of code.
• User accounts. One hardcoded API key on the server.

The FDE rule: Every hour you spend on an edge case is an hour stolen from testing the golden path with real customer data. The prototype’s job is to prove value, not to be production-ready.

A critical part of this phase is prompt engineering. You aren’t fine-tuning a model. You’re writing a system prompt that constrains the LLM to act as a deterministic clause classifier. The prompt includes:

• The exact JSON schema you want returned.
• A definition of “deviation” from the playbook.
• A few-shot example with a clause that is clearly standard and one that is clearly non-standard.

You test this prompt against 3 real contracts the customer gave you. You iterate until the highlights match what the paralegal would do manually, at least 90% of the time. The 10% miss rate is acceptable for a prototype. You’ll fix it in Week 3 if the customer signs on.

Day 4: The Hardest Part – Customer-Side Integration

This is where the forward deployed engineer workflow diverges completely from normal software engineering. You don’t ship the prototype on your infrastructure. You have to get it running in the customer’s environment.

This is always, always the hardest day. The customer’s environment is a black box of undocumented firewall rules, proxy servers that strip auth headers, and a security team that will not let you run a Python script on a machine that touches production data.

Your playbook for Day 4:

1. Deploy the simplest possible way first. If the customer allows it, run the Streamlit app on a small EC2 instance in their VPC. If not, ask if you can run it on a locked-down VM on a paralegal’s desktop machine. The goal is to get it running on something inside their network so it can reach their S3 bucket or file share.

2. Don’t fight the security team. Make them your QA. Schedule a 15-minute call with the infosec lead. Show them exactly what the script does: “It reads a .docx, sends text to OpenAI’s API, and writes a new .docx. No data is stored. Here’s the outbound HTTPS call.” Often, they’ll approve it faster if you’re transparent and the scope is tiny.

3. Have a fallback that requires zero network changes. If the API call to OpenAI is blocked, have a local model ready. A quantized Llama 3 8B running via Ollama can run on a laptop without internet access. The quality will be lower, but the prototype will still work. This is your insurance policy.

For more on navigating these treacherous integration waters, especially when you have no direct access to the system, the playbook in Debugging in the Customer's Environment Without Direct Access: A Black-Box Playbook is essential reading.

Day 5: Ship It, Then Instrument It

Friday morning. The prototype is running in the customer’s environment. The paralegal is about to test it with a real contract that just came in.

You don’t just hand her the URL and hope. You sit with her (physically or over Zoom) and watch her use it. This is the most valuable 30 minutes of the entire week.

You’re watching for:

• Where does she hesitate? If she hovers over the upload button for 5 seconds, the UI is confusing.
• What does she say out loud? “Wait, why is clause 14 not highlighted? That’s clearly a deviation from our playbook.” That’s a prompt failure you need to fix immediately.
• What does she try to do that the tool doesn’t support? If she tries to drag-and-drop the file instead of clicking “Browse,” you need to add drag-and-drop support. If she asks “Can I edit the highlights?” you’ve identified the Week 2 feature.

You also instrument the prototype with the simplest possible telemetry. No Datadog. No OpenTelemetry. Just a log file that records:

• Timestamp of each request.
• Filename of the uploaded contract.
• Number of clauses found.
• Number of deviations flagged.
• Any errors from the LLM API.

This log file is your evidence. When you present the results to the customer’s VP on Monday, you’ll say: “We processed three real contracts. The tool flagged 22 deviations total. Your paralegal confirmed 20 were accurate. The two misses were because of a table in the contract, which we’ll handle in the next iteration. She spent 10 minutes reviewing the highlights instead of 4 hours doing it manually. That’s a 96% time reduction on the first step of the review process.”

That’s the language that gets a prototype converted into a paid engagement.

Why This Workflow Commands High Comp

The forward deployed engineer workflow is why FDEs at top firms command $200K-$350K+ total compensation. You aren’t being paid to write code. You’re being paid to:

• Navigate a messy enterprise environment.
• Extract a crisp technical scope from an ambiguous business pain.
• Build and ship a working solution in 5 days.
• Communicate the business impact in terms the customer’s leadership cares about.

If you’re building these skills, the technical side is table stakes. The differentiator is the ability to operate in the customer’s world. For a granular look at how these days actually unfold, see What a Forward Deployed Engineer Actually Does in a Week: A Daily Breakdown.

The FDE’s Secret Weapon: Pre-Built Modules

Experienced FDEs don’t start from scratch every time. They maintain a personal library of “LEGO bricks” – small, reusable code modules that solve common enterprise integration problems. A module for “ingest a .docx and chunk by heading.” A module for “deploy a Streamlit app behind a customer’s SSO proxy.” A module for “run a local LLM with Ollama as a fallback.”

Before the scoping call even ends, a senior FDE is mentally assembling the prototype from these bricks. They know they can build the contract reviewer because they’ve already built a Customer-Review Sentiment Dashboard from Scraped Reviews that used the same chunking and LLM-calling pattern. The domain is different, but the atomic workflow is the same: chunk text, classify each chunk with an LLM, reassemble with annotations.

This is why FDEs who invest in building their module library compound their effectiveness. Each prototype becomes faster to build than the last.

FAQ: Forward Deployed Engineer Workflow

What tools do FDEs use most? Python (FastAPI, Streamlit, python-docx, LangChain for complex chains but raw API calls for simple ones), OpenAI/Anthropic APIs, ChromaDB or FAISS for vector search, Docker only when absolutely necessary, and the customer’s existing cloud CLI. The stack is deliberately boring.

How does this differ from a solutions engineer? Solutions engineers typically demo existing products and configure them. FDEs build new, custom prototypes that are not on the product roadmap. The output is working code, not a slide deck.

What if the prototype fails? A “failed” prototype that clearly demonstrates why a problem is technically harder than expected is still a success. You’ve saved the customer from a 6-month internal project that would have hit the same wall. Document the failure mode precisely and propose the next experiment.

How do you handle data sensitivity? Always ask on Day 0: “Can this data leave your network?” If no, plan for a local model from the start. Never promise a cloud-based LLM and then have to pivot on Day 4.

What’s the career path for an FDE? FDEs typically move into three directions: (1) Product management, because they understand customer problems better than anyone. (2) Founding their own company, because they’ve seen the same unsolved problem across 10 customers. (3) Senior/Principal FDE, where they handle the hardest, highest-value customer engagements and mentor new FDEs. The role is not a stepping stone to a pure software engineering role; it’s a parallel track that values breadth and customer intuition over depth in a single technical domain.