How FDEs Turn a Messy Customer Problem into a Shipped Prototype in 7 Days

The FDE Prototype Mandate: Speed Over Perfection

A customer doesn't buy a white paper. They buy a feeling of relief. As a Forward Deployed Engineer, your job isn't to build a perfect system; it's to collapse the time between a vague, painful problem and a tangible, interactive artifact that proves it can be solved.

The "7-day prototype" is the atomic unit of FDE work. It’s not a hackathon project. It’s a high-stakes, customer-facing engineering sprint where the output must run on their messy data, in their environment, solving their specific constraint. This playbook breaks down exactly how to execute that week without burning out or over-engineering.

Day 0: Scoping the Mess (The One-Hour Rule)

You receive a sprawling problem statement: “We need to automate our supplier compliance checks from 50,000 PDFs, but they’re in 12 languages, and our legal team needs a confidence score.”

Your first instinct is to reach for a RAG pipeline. Stop. The first hour is purely about constraint extraction, not solutioning.

The Scoping Framework:

1. The Monday Morning Test: “If we had a magic button, what specific output would you bring to your stand-up on Monday?” This forces them to define the artifact, not the system. (Answer: “A CSV of high-risk suppliers with the specific clause highlighted.”)
2. Data Gravity: Where does the data live right now? (A network drive? An S3 bucket they forgot they had? A vendor API with a rate limit of 1 request per second?). You must touch this data on Day 1.
3. The Failure Mode: “If this prototype is only 70% accurate, is it useless or a massive time-saver?” If they demand 100% accuracy, you don't have a prototype problem; you have a production engineering problem. Renegotiate the week’s goal to a triage tool, not a decision engine.

Output of Day 0: A single Notion page or Slack canvas with the agreed-upon artifact definition, a sample of the raw input data, and a hard list of out-of-scope items for the week.

Architecture: Choosing the Duct Tape and the Steel

You have 7 days. You cannot build a microservices mesh. You need a “steel thread” architecture: a minimal end-to-end slice that touches all critical components, held together with robust duct tape.

The standard FDE prototype stack in 2026 is a three-layer model:

The Steel (Unchangeable): The core logic that differentiates the solution. If you’re doing compliance checks, this is the LLM prompt chain and the retrieval mechanism. Use tools with high leverage: instructor for structured extraction, lancedb for embedded search if needed.

The Duct Tape (Replaceable): Everything else. The UI is Streamlit. The auth is a hardcoded token in an environment variable. The scheduler is a while True: loop with a time.sleep(3600). This is not technical debt; it’s intentional speed. You explicitly label these as “prototype scaffolding” in the code comments.

Days 1-3: Building the Happy Path with Zero UX Polish

Start with the algorithm, not the interface. The biggest mistake FDEs make is building a beautiful UI that wraps a broken core.

Day 1: Get the core logic working on one perfectly clean example. Hardcode the input. If it’s an LLM pipeline, spend the day on prompt engineering and output validation using pydantic models. You should have a passing unit test by end of day.

Day 2: Build the minimal UI only to expose the logic to the customer. This is not a product UI. It’s a debug window. File uploader, a “Process” button, and a raw JSON/text output pane. Deploy it using a single docker-compose up command on a cloud VM. Send the IP address to the customer by end of day.

Day 3: The “Silent Partner” day. You don’t build new features. You watch the customer use the ugly UI (via screen share) and silently log every place they hesitate, misunderstand the output, or request a feature. Do not implement anything yet; just collect the signals.

Days 4-5: Injecting the Customer’s Real Data

This is where prototypes die. The clean example worked, but the real data is a nightmare: corrupted PDFs, missing metadata, encoding issues.

The FDE Data Strategy:

• Fail Loudly: Don't silently skip bad records. Create a quarantine/ folder and move broken files there. The customer needs to see the volume of garbage data.
• The 80/20 Parse: You don't need to write a universal parser. Write a targeted parser that handles the top 5 document structures in the batch. For the rest, fall back to a raw text dump with a warning: “Unstructured text extracted — review needed.”
• Cost Guardrails: If using an LLM API, estimate the total token cost for the full batch before running it. Present the estimate to the customer: “Processing all 50,000 PDFs will cost ~$400 in API credits. Should we run a 1,000-document sample first?” This protects you and builds trust. For more on managing complex technical topics with LLMs, see our pattern guide for engineers.

Days 6-7: The Hardening Sprint and the Hand-off

You have a working pipeline. Now you make it look like you’ve been working on it for a month.

Day 6: Error Handling and Observability. Add structured logging (JSON logs to stdout). Wrap the core loop in a try/except that sends a Slack webhook on failure. Add a simple promptfoo eval to compare your current prompt against a baseline. This is the difference between a script and a prototype.

Day 7: The Artifact Hand-off. You are not delivering code. You are delivering a decision package. Prepare three things:

1. A 5-minute Loom video walking through the working prototype with their data.
2. A one-page PDF “Path to Production” listing the prototype scaffolding (the duct tape) that must be replaced, with rough time estimates (e.g., “Replace Streamlit with React: 2 weeks”).
3. The code repository with a README.md that starts with the problem statement, not the setup instructions.

If you’re writing customer-facing documentation, the narrative structure matters more than the technical detail. We cover this in depth in our piece on writing technical docs that stakeholders actually read.

Compensation Context: Why This Skill Commands $250k+

This 7-day execution capability is not just a workflow; it's a massive revenue accelerator. Companies don't pay for code; they pay for de-risked decisions.

Note: Top-tier AI labs like Anthropic and OpenAI often add substantial equity grants on top of these base ranges. For a deep dive into compensation at one of the leading labs, see our breakdown of Forward Deployed Software Engineer OpenAI salary & compensation.

The ability to ship a working prototype in a week directly correlates with the upper bands. You're not just an engineer; you're a technical closer.

FAQ: Common Prototype Week Scenarios

Q: The customer demands a feature that will take 3 days alone. What do I do? A: Use the “Time vs. Impact” matrix. Say, “I can build the automated report generation, but that means we won’t have time to test it on the full dataset. Which is higher priority: the feature or the coverage?” Push the decision back to them.

Q: The prototype works but is too slow for the full dataset. A: Ship it with a progress bar and an async processing note. Speed is a production concern. A slow working prototype that proves the concept is infinitely more valuable than a fast, non-existent one. Document the latency in the “Path to Production” hand-off.

Q: How do I handle security concerns in a prototype? A: Never, ever use real PII in development. Generate synthetic data or use a hashing script on the raw data before it touches your machine. If the customer insists on PII, insist on a VPN and their cloud environment. Do not let sensitive data hit your local laptop.

Q: Do I need Kubernetes for a prototype? A: Almost never. A single VM with Docker Compose is sufficient for 99% of prototypes. Kubernetes is a production scaling tool, not a prototyping tool. However, understanding it is critical when you transition the prototype to their engineering team. See our analysis of why Kubernetes is a core FDE skill.