How FDEs Turn a Messy Customer Problem Into a Shipped Prototype in a Single Week

The enterprise customer doesn’t have a spec. They have a Slack thread, three forwarded emails, and a VP who said “we need AI in this.” That’s the starting gun for a Forward Deployed Engineer.

While core engineering roadmaps stretch into quarters, the FDE’s timeline is a single week. The goal isn’t a scalable system. It’s a proof of existence—a tangible artifact that turns a vague anxiety into a concrete buying decision.

This is the exact playbook for compressing that messy intake into a shipped prototype by Friday, including the architectural decisions, the tools that ship, and the career capital you build when you do it consistently.

The FDE’s Week: A $250k/Year Compressor

FDEs occupy a strange compensation band. Base salaries hover between $160k–$220k, with equity pushing total comp into the $250k–$350k range at growth-stage companies. That premium exists for one reason: the role compresses three functions—solutions architect, product manager, and engineer—into a single operator who ships against ambiguity.

A core engineer might spend two weeks scoping. An FDE spends two hours. The output isn’t a production system. It’s a decision accelerator. The prototype either proves the integration is trivial (the customer buys) or exposes the landmines early (the deal gets descoped before it burns engineering months).

This compression skill is what makes FDEs the best startup prep you can get, but it requires a repeatable process. Here’s the week.

Day 1: The Messy Intake (Don’t Just Nod)

Monday morning, you’re on a call with the customer’s “technical stakeholder”—often a director of engineering who’s been told to evaluate your platform. They’ll describe the problem in solution-shaped language: “We need a real-time dashboard that ingests our Jira instance and predicts sprint risk.”

That’s not the problem. That’s their guess at a solution.

Your job in the first 90 minutes is to excavate the actual pain. The framework:

• What’s the trigger? “What happened last quarter that made this urgent?” (Answer is usually a missed deadline, a board-level visibility gap, or a competitor win.)
• What’s the current worst-case workaround? “If we do nothing, what’s the manual process today?” (A PM exports CSV, massages in Excel, presents on Friday.)
• What’s the smallest possible win? “If you could only get one thing by Friday, what makes this worth continuing?”

The output of Day 1 is a single Notion doc with three sections:

1. The real problem (one sentence, in the customer’s words)
2. The minimum viable demo (a bullet list of 2-3 things the prototype must show)
3. The explicit anti-goals (auth, multi-tenancy, error handling, scale—all explicitly declared out of scope)

You send this doc by end of day with a one-line ask: “Does this match what’s in your head? If yes, you’ll see a working version Thursday.”

Day 2: The Architecture That Can’t Fail

Tuesday is about choosing the stack that guarantees you ship by Thursday night. This is not the time for novelty. The rule: use what you’ve already debugged in production or in a previous prototype.

A typical FDE prototype stack for an AI-adjacent problem looks like this:

The architecture has three principles:

1. Data ingress is a script, not a pipeline. You write a Python script that pulls from the customer’s API, dumps to a local SQLite file, and never runs again unless manually triggered. No cron, no Kafka.

2. The LLM call is a single prompt with a hardcoded system message. You are not building a RAG pipeline in a week. You are showing what the output looks like. If the customer asks “does it handle edge case X?” the answer is “not yet—that’s the next conversation after you see the core flow work.”

3. Auth is a hardcoded token. You generate one API key, embed it in the frontend, and tell the customer this is a single-user demo. If they ask about SSO, you smile and say “that’s the easy part once we’re aligned on the value.”

For a concrete example of this stack in action—specifically how to structure the data ingestion and LLM layer for a customer-facing tool—see our walkthrough on building a codebase Q&A tool with local inference. The same pattern applies: ingest, embed, query, display. Just compress the scope to one happy path.

Day 3-4: Building the Happy Path, Ignoring the Rest

Wednesday and Thursday are a single block. You are building exactly one user journey: the sequence of steps that makes the customer’s eyes go wide.

The Build Order

The key discipline: when you hit a bug that affects the happy path, you fix it immediately. When you hit a bug that only manifests on edge cases outside the demo dataset, you write a comment // TODO: handle null state and move on.

This is the hardest part for engineers trained on production systems. The prototype is not technical debt—it’s a decision artifact. The code will be thrown away. What survives is the customer’s conviction that the integration is possible.

The LLM Layer Specifically

If the prototype involves LLM output, you have exactly two concerns:

1. The output must be structurally consistent. Not correct in every case—consistent. If you’re generating sprint risk summaries, every output needs the same JSON shape so the UI doesn’t break. Use constrained generation (guidance, outlines, or a simple Pydantic parser) to enforce this.

2. Latency must feel real-time. If the LLM call takes 8 seconds, the demo feels broken. Solutions: stream tokens, use a fast model (Groq’s Llama 3 70B is a common choice for demos), or pre-compute the LLM output and play it back as if live. The last option is perfectly acceptable for a first demo. The customer is evaluating the output quality, not your inference infrastructure.

For more on structuring prompts that produce reliable, constrained output in customer-facing contexts, read our deep dive on constraint injection for financial prompts. The same techniques apply to any domain where the LLM must speak in a specific schema.

Day 5: The Demo That Closes the Gap

Friday is demo day. You are not presenting slides. You are sharing your screen with the working prototype, using the customer’s own data.

The Demo Structure (30 minutes)

• Minute 0-5: Recap the problem statement from Monday’s doc. “This is what we heard. Tell me if we got it wrong.”
• Minute 5-15: Run the happy path live. No commentary, just the flow. The customer watches their Jira data turn into a risk dashboard. Silence is good—it means they’re processing.
• Minute 15-25: Pause and ask: “What’s the one thing you’d change?” This is the most important question. The answer tells you whether the prototype hit the mark or whether the real problem is something else entirely.
• Minute 25-30: Explicit next step. Never end a demo without a concrete follow-up: “We’ll take your feedback, scope the production version, and have a timeline by Tuesday.”

What Happens After the Demo

Three outcomes, and all of them are wins:

1. The customer wants to buy. You hand off to the solutions architect and core engineering team. Your prototype becomes a spec, not a codebase. Read our guide on when and how to hand off a prototype to core engineering for the exact transition playbook.

2. The customer wants changes. You iterate for another week. This is normal. The prototype surfaced the real requirements. You’ve saved core engineering months of building the wrong thing.

3. The customer realizes the integration is harder than expected. This is also a win. You’ve descoped a deal that would have burned engineering resources for six months. The account team can now price the integration accurately or walk away clean.

What This Prototype Is Not

A common failure mode: the FDE builds a prototype, the customer loves it, and the account executive says “great, ship it to production next week.”

No. The prototype is a decision artifact. It has no error handling, no auth, no scale, no monitoring, no CI/CD. It runs on your laptop. Shipping it to production is malpractice.

The gap between a prototype and a product is real, and it’s where most AI demos die. We’ve written about this extensively in our piece on the prototype-product gap and why LLM-generated code still needs systems thinking. The prototype proves the concept. The product requires a different set of muscles.

FAQ: Prototyping Under Fire

How much does it cost to get a prototype made?

Internally, an FDE’s fully-loaded weekly cost is roughly $5,000–$7,000 (based on $250k–$350k total comp). A one-week prototype costs the company that amount in salary, plus whatever cloud credits the LLM calls consume (typically under $50 for a demo). Externally, agencies charge $15k–$50k for a similar scope, but they lack the customer context and the ability to iterate in real-time on a call. The FDE model wins on both speed and relevance.

What is a prototype example?

A concrete example from this playbook: a customer says “we need AI to predict sprint risk from our Jira data.” The FDE builds a single-page Next.js app that pulls the last 4 sprints via Jira API, runs a single LLM prompt summarizing velocity trends and overdue tickets, and displays the result in a simple dashboard. It works for exactly one Jira project, with one hardcoded user. That’s the prototype. It’s not a product—it’s a 5-day answer to the question “can this work?”

How to create a prototype of the product?

Follow the week structure above: Day 1 for problem definition, Day 2 for architecture, Days 3-4 for building the single happy path, Day 5 for demo and iteration. The key is constraint: one user journey, one data source, one LLM prompt chain, zero production concerns. If you need a concrete starter project, our YouTube-to-blog repurposing agent uses the same pattern—ingest, transform, LLM, display—and you can adapt the architecture to any customer data source.

Who can make a prototype of my invention?

If you’re a company evaluating an AI platform, your vendor’s FDE team exists precisely for this. If you’re an individual inventor, the skillset is learnable. The FDE approach—compress ambiguity, build the happy path, demo with real data—is a discipline you can apply regardless of who writes the code. The market rate for a skilled prototyping engineer is high because the skill isn’t coding; it’s the judgment to know what not to build.

How do I answer “turn a messy customer problem into a shipped prototype” in an interview?

FDE interviews often include a take-home or live exercise with exactly this prompt. The winning answer follows the framework above: (1) Ask clarifying questions to excavate the real problem, not the customer’s guessed solution. (2) Explicitly define what’s in scope and what’s an anti-goal. (3) Choose boring, proven tools. (4) Build exactly one happy path. (5) End with a demo that uses the customer’s data. The interviewer is evaluating your ability to scope ruthlessly, not your ability to build a perfect system.