How an FDE Turns a Messy Enterprise Problem into a Shipped Prototype in 7 Days

The Monday Morning Call: The "Simple" Data Request

You’re three weeks into an embed at a Fortune 500 logistics customer. Your calendar has a 30-minute block titled “Quick data pull – inventory aging.” You join and immediately spot the cast: a VP of Supply Chain, two senior data analysts you’ve never met, and your account executive, who looks like she’s already been on this call for 45 minutes.

The VP opens: “We need a dashboard that shows real-time inventory aging across our 14 distribution centers. Our SAP data is clean. Should take a day, right?”

You’ve heard this before. The request is a “dashboard,” but the pain is something else. You ask one question: “What decision will this dashboard change by Wednesday morning?”

Silence. Then the VP admits: “We’re holding $4.2M in inventory that’s over 90 days old. The CFO wants a write-down recommendation by Friday. We don’t actually know which SKUs are stuck, in which DCs, or why.”

There it is. The real problem: a one-time analytical question dressed as an infinite product feature. Your job as a forward deployed engineer isn’t to build a dashboard. It’s to ship a prototype that answers the CFO’s question before Friday’s deadline. That’s the week.

Day 1: Scoping the Real Problem (Not What They Asked For)

Classic enterprise trap: the customer asks for a solution (dashboard) instead of stating the problem (which SKUs do we write down?). Your first task is scope negotiation.

You spend two hours with the data analysts. The “clean SAP data” turns out to be three separate extracts—inventory positions, sales orders, and receiving logs—each with different SKU identifier formats. No common join key. The analysts have been manually VLOOKUP-ing these in Excel every Monday, a process that takes one person 6 hours and breaks whenever a DC adds a new product line.

You write the problem statement on a shared doc:

Actual problem: Identify all SKUs with zero sales movement in 90+ days, grouped by distribution center, with the last receiving date, so the CFO can calculate inventory write-down exposure by Thursday EOD.

Constraints: On-prem data only (no cloud uploads), must run on the analytics team’s Windows machine, no production database access.

You send this to the VP with a note: “Confirm this is the question. If yes, I’ll have a working prototype by Thursday noon, not a dashboard.” She replies in 4 minutes: “Confirmed. Go.”

Decision log entry: Killed the dashboard. Scoped to a single analytical query. Bought yourself a real deadline and a clear success criterion.

Day 2: Architecture Decision in a Constrained Environment

You can’t spin up a Postgres instance. You can’t use the cloud. The analytics team’s machine has Python 3.9, VS Code, and a lot of Excel. This is the actual enterprise environment for an FDE: you build where the customer lives, not where you’re comfortable.

You sketch the data flow on a whiteboard. Here’s the architecture:

Three decisions matter here:

1. SQLite over pandas-only. The join logic is messy (three different SKU formats). Loading into SQLite lets you write readable SQL and hand the query to the analysts later. They can modify it without learning pandas.

2. SKU normalization as a separate step. You write a small mapping table that translates each DC’s internal SKU format to a common identifier. This is the part that will break in production—so you isolate it.

3. Output is a CSV, not a dashboard. The analysts live in Excel. Ship the artifact they can actually use.

You spend the afternoon writing the ingestion script. By 6 PM, you have all three CSVs loaded into SQLite with normalized keys. 212,000 rows. The analysts confirm the row counts match their manual process. First win.

Day 3: Building the Critical Path (and Ignoring the UI)

You have 48 hours until the CFO meeting. The temptation is to make something pretty. Resist it.

The critical path is one SQL query:

SELECT
    dc.name AS distribution_center,
    inv.sku_normalized,
    inv.quantity_on_hand,
    inv.unit_cost,
    inv.quantity_on_hand * inv.unit_cost AS exposure,
    MAX(recv.received_date) AS last_received,
    MAX(sales.order_date) AS last_sold
FROM inventory inv
LEFT JOIN receiving recv ON inv.sku_normalized = recv.sku_normalized
LEFT JOIN sales ON inv.sku_normalized = sales.sku_normalized
WHERE sales.order_date IS NULL
   OR sales.order_date < date('now', '-90 days')
GROUP BY 1, 2
ORDER BY exposure DESC;

You run it. 847 SKUs with $3.8M in exposure. The number is close to the VP’s $4.2M estimate. You’re in the right ballpark.

But you notice something: 23 SKUs show exposure but have last_received dates in the future. Data entry errors at DC #7. You flag these in a separate “data quality” tab. This is the kind of thing that kills trust if you don’t catch it before the customer does.

You spend zero minutes on charts. The output is a CSV with six columns. You email it to the analysts at 4 PM with a note: “Does this pass the sniff test? Call out anything that looks wrong.”

Day 4: The Hard Pivot When the API Returns Garbage

Thursday morning. You planned to spend today on edge cases. Instead, you get a Slack message: “DC #3 just sent us a new extract. The format is completely different.”

You open the file. It’s not a CSV. It’s an Excel workbook with merged cells, three header rows, and summary totals embedded mid-sheet. The kind of file a warehouse manager designed in 2014 and never changed.

You have two choices: ask them to reformat it (24-hour delay, maybe longer) or write a parser. You write the parser.

def parse_dc3_abomination(filepath):
    df = pd.read_excel(filepath, header=None)
    # Find the actual data start: row with "SKU" in col A
    header_row = df[df.iloc[:, 0].str.contains('SKU', na=False)].index[0]
    # Read again from that row
    df_clean = pd.read_excel(filepath, skiprows=header_row)
    # Drop summary rows (where col B is blank)
    df_clean = df_clean[df_clean.iloc[:, 1].notna()]
    return df_clean

It’s ugly. It’s 14 lines. It works on their exact file. You don’t generalize it. This is a prototype, not a product. The FDE instinct is knowing when to write throwaway code.

By 2 PM, DC #3’s data is ingested. The exposure number updates to $4.1M. You’re within $100K of the VP’s estimate.

Day 5: Customer Validation Without a Finished Product

Friday morning. The CFO meeting is at 2 PM. You don’t have a product. You have a Python script, a SQLite database, and a CSV. That’s enough.

You sit with the lead analyst for 45 minutes. She runs the script herself on her machine. She modifies the aging threshold from 90 days to 120 days (a question the CFO always asks). The SQL makes it trivial: change one WHERE clause.

She finds two SKUs where the exposure calculation is wrong—the unit cost field was in a different currency for a Canadian DC. You fix it together in 10 minutes. She’s now co-owner of the output, not just a recipient. This is the difference between a prototype they’ll use and a prototype they’ll ignore.

Validation checklist:

• ✅ Runs on their machine
• ✅ They can modify the query themselves
• ✅ Output matches their intuition (within explainable variance)
• ✅ They found and fixed a bug with you

You don’t present at the CFO meeting. The analyst does, using the CSV in a pivot table she built herself. The CFO gets her answer. The VP sends you a two-word Slack: “It worked.”

Day 6: Hardening and the "Demo-Ready" Standard

The problem is solved, but your job isn’t done. The analyst asks: “Can I run this next month without you?”

You spend Saturday morning on hardening—not building features, but removing failure modes:

1. README.md with exact steps: where to put the files, which Python packages to install, what to do when a DC sends a new format.
2. Error handling for the three most common failure modes (missing file, new SKU format, merged cells in Excel).
3. A 5-minute Loom video walking through the entire process, from downloading the SAP extracts to opening the output CSV.

You don’t add a UI. You don’t add scheduling. You don’t add email alerts. Those are product features. Your job is to make the prototype survivable until core engineering can productionize it—or until the customer decides it’s good enough as-is (which happens more often than you’d think).

This is the handoff standard: a competent analyst who’s never met you can run it successfully from your instructions alone. For more on what a full FDE handoff looks like, see how an FDE hands off a prototype to core engineering.

Day 7: Ship, Handoff, and the Follow-Up Email

Monday of week two. You send the wrap-up email:

Subject: Inventory aging prototype – what we built, what happens next

What we shipped: A Python + SQLite pipeline that ingests SAP extracts from all 14 DCs, normalizes SKUs, and outputs a CSV of aged inventory with dollar exposure. Ran successfully on [Analyst]’s machine. Delivered CFO recommendation on time.

What it doesn’t do (intentionally): No dashboard, no scheduling, no automated data pulls. These are product decisions, not week-one prototype decisions.

What I’d recommend next: The SKU normalization table is the fragile piece. If DCs change formats, the mapping breaks. Core engineering should own a canonical SKU service. Happy to spec this out.

Artifacts attached: Script, README, Loom walkthrough, sample output.

You CC your engineering manager and the account team. This email serves three purposes: it documents what you built, sets boundaries on what you didn’t, and creates a clear handoff path. For a deeper look at how Palantir-style FDEs run these embed rituals, see FDE embed rituals, artifacts, and trust.

Comp Reality Check: What a Week Like This Is Worth

Let’s talk numbers, because “forward deployed engineer week” searches often lead to comp questions.

FDE compensation breaks into three bands:

Equity is the multiplier. At Palantir, senior FDEs with strong stock performance have hit $500K–$1M+ total comp in peak years. The role pays for impact, not lines of code—and a week like the one above, where you save a customer from a $4M write-down surprise, is exactly the kind of impact that gets noticed at comp review.

A note on the $500K question that shows up in People Also Ask: engineers hitting that number are typically senior FDEs at public companies with appreciating stock, or founding FDEs at high-growth startups where equity is a significant bet. It’s achievable, but it correlates with owning customer outcomes, not just shipping features.

If you’re building the skills to operate at this level—moving from “I can code” to “I can walk into a messy enterprise, find the real problem, and ship something that matters in a week”—that’s exactly the gap FDE Coach is designed to close.

FAQ: Forward Deployed Engineer Week

What does it mean to be a forward-deployed engineer?

A forward deployed engineer (FDE) embeds directly with customer teams—often on-site or in their environments—to understand their actual problems, build working prototypes rapidly, and bridge the gap between sales promises and product reality. Unlike pure software engineers, FDEs own the customer outcome end-to-end: scoping, building, validating, and handing off. The role originated at Palantir but has spread across enterprise AI and infrastructure companies. For a week-in-the-life breakdown, see what an FDE actually does in a week.

What is the theme for Engineers Week in 2026?

Engineers Week 2026 (February 15–21) carries the theme “Design Your Future,” focused on how engineers across disciplines shape the systems, infrastructure, and tools that define daily life. For forward deployed engineers specifically, the theme resonates: FDEs design the future of how enterprise software gets adopted, one prototype at a time.

How much do FDEs get paid?

Entry-level FDEs typically start at $130K–$170K base, with total comp (base + bonus + equity) ranging from $160K–$220K. Mid-level FDEs earn $220K–$350K total comp. Senior FDEs at public companies can reach $350K–$600K+, with top performers exceeding $1M in years with strong stock appreciation. The premium exists because FDEs combine engineering skill with customer judgment—a rare pairing.

What engineers make $500,000?

Engineers earning $500K+ typically fall into a few categories: senior FDEs at companies like Palantir or high-growth enterprise startups, staff/principal engineers at FAANG companies with strong stock performance, and specialized AI/ML engineers at top labs. For FDEs, the $500K threshold usually requires 7+ years of experience, ownership of significant customer accounts, and a track record of shaping both customer outcomes and internal product direction. The path runs through impact, not tenure.

How do I get better at the one-week prototype sprint?

The skill isn’t coding faster—it’s scoping ruthlessly. The FDEs who ship in a week are the ones who say no to 80% of what the customer initially asks for, identify the one question that actually matters, and build only what answers it. Practice this on side projects: take a vague request (“build me a dashboard”), find the underlying decision, and ship the minimal artifact that enables that decision. The LLM enterprise deployment case study walks through another real example of this pattern.

What’s the difference between an FDE prototype and a product feature?

An FDE prototype answers a specific customer question with a specific deadline. It runs in the customer’s environment, uses their actual (messy) data, and is designed to be thrown away or handed off. A product feature is generalized, tested across many customers, and maintained indefinitely. The FDE’s job is to prove value fast; core engineering’s job is to scale that value. Confusing the two is how prototypes become unmaintainable products.