From Messy Problem to Shipped Prototype: The FDE Weekly Workflow

The FDE Operating Cadence: Why a Week is the Magic Unit

Most software engineers optimize for months-long roadmaps. Forward Deployed Engineers optimize for the next five business days. If you haven’t shipped something that changes the customer’s perception of what’s possible by Friday afternoon, you’ve lost momentum you can’t recover.

This isn’t a hackathon gimmick. Enterprise AI deals close when a technical champion on the customer side can show their VP a working prototype that touches real data. The weekly workflow is the atomic unit of that trust. Break it, and the proof-of-concept dies in procurement limbo.

Here’s exactly how that week looks, from the Monday morning ambiguous problem statement to the Friday handoff artifact.

Monday Morning: Scoping the Mess (Without Access)

You usually start the week with a Slack message that reads something like:

“Hey, the Acme Corp team wants to auto-triage their support tickets. They have 10,000 PDFs and a legacy SQL Server. Can you take a look?”

Your first job is not to build. It’s to collapse the ambiguity into a decision document in under three hours. The core constraint: you almost never have direct access to their environment on day one.

The 3-Hour Scoping Protocol

1. The 15-Minute Voice Call (Non-Negotiable)
   Never scope over email. Get the customer’s lead engineer on a call and ask only three questions:

   • “Show me the exact input a user submits and the exact output you want.”
   • “What’s the one metric that makes this project a failure if it doesn’t move?”
   • “What’s the ugliest, most annoying constraint you’re dealing with right now?”

2. Data Archaeology (Remote)
   Request a sanitized sample of 10-20 records. If they can’t produce that by end of day Monday, the project is already in the danger zone. Parse the sample locally with a quick Python script to surface encoding horrors, nested JSON blobs masquerading as text, or 40-page PDFs where page 39 contains the only signal.

3. The One-Pager
   Write a scope doc that fits on a single Notion page. Sections: Input Schema, Output Spec, Known Landmines, Tuesday Morning Hypothesis. Send it to the customer by 11:00 AM. If they don’t reply with a thumbs-up by 2:00 PM, you ping again. No reply by EOD? You de-prioritize and work on another engagement. The weekly workflow only functions when the customer matches your tempo.

Tooling for Monday

• json_repair: For when their “JSON export” is actually five concatenated objects with trailing commas.
• pandas + tabulate: Quick profile of the sample data. Print the worst 5 rows to the terminal so you internalize the mess.
• ffprobe/poppler: If they’ve attached media files, extract text before you even think about an LLM pipeline.

Tuesday–Wednesday: The “Ugly Baby” Architecture Sprint

With the scope locked, you have roughly 48 hours to produce a working end-to-end wireframe. The key rule: no new infrastructure that requires a ticket on the customer’s side. You build against their existing shape, even if it’s ugly.

The Pattern: Sidecar Intelligence

You’re almost never allowed to modify their production schema. The standard FDE pattern is a sidecar service that reads from their existing dump, processes, and writes results to a new table or a CSV endpoint they can ingest.

Tuesday: The Brutal First Pass

Write the dumbest possible pipeline that survives their worst data point. Do not fine-tune. Do not build a UI. Your deliverable on Tuesday at 6:00 PM is a terminal command:

python run.py --input sample_data/ --output results.csv

If that command doesn’t produce a CSV with at least one surprisingly accurate column by dinner, you’ve chosen the wrong approach. Pivot immediately.

This is where the FDE skill stack diverges from pure ML engineering. You’re not optimizing for F1 score on a static benchmark. You’re optimizing for the moment the customer’s eyes widen. That often means using a heavier model (like Gemini or GPT-4o) for the first pass to guarantee quality, then swapping in a distilled model later if latency or cost becomes an objection. For a deep dive on running such models under tight resource constraints, our breakdown of Running an 80B Qwen Model in 4.3 GB RAM on a Mac shows the kind of quantization tricks that make local prototyping viable even on a laptop during a customer visit.

Wednesday: The “Enterprise Reality” Layer

Wednesday is for hardening. Add exactly three things:

1. Error handling for the worst record. Find the one PDF that’s a scanned image of a fax. If your pipeline crashes, wrap it in a try-catch that writes a needs_human_review flag instead.
2. A 5-line Streamlit/Gradio UI. Not for production, but so the customer’s business analyst can click around without asking you to run the script.
3. A latency log. Time every step. When the VP asks “how fast is this?”, you need a concrete answer, not a guess.

Thursday: The Hardest Demo of Your Life

Thursday is demo day. This isn’t a polished product launch. It’s a live-fire exercise where you show the prototype working on data the customer provided this week.

The structure of a winning Thursday demo:

• Minute 0-2: Recap the Monday scope. Remind them this is a 4-day prototype.
• Minute 2-8: Live run. No slides. Upload their own sample file and let the pipeline execute in real time. If it fails, debug live. A live fix builds more trust than a canned success.
• Minute 8-12: Show the ugly CSV or UI. Walk through 3 examples where it nailed it and 1 where it struggled. Own the struggle.
• Minute 12-15: Next steps. Propose a 2-week hardening phase or a clean handoff to their internal team.

The Psychology of the Live Demo

Enterprise customers have been burned by vendors who show up with a year-old slide deck. When you show a working artifact built against their actual data in 4 days, you redefine their expectations of what’s possible. This is the moment an FDE earns their comp.

Friday: Packaging the Artifact and Closing the Loop

Friday is about making your work durable. The customer might not touch this code for two weeks while legal reviews the contract. When they come back, it needs to still run.

The Friday Handoff Checklist

1. README.md with exact setup steps. Assume zero Python knowledge. Include the pip install command, the required environment variables, and a one-liner to run the demo.
2. A sample_data/ directory with the scrubbed examples you used. Never leave them hunting for the right file format.
3. A 2-minute Loom video walking through the run. VPs share videos; they don’t read READMEs.
4. Internal write-up for your own team. What worked? What was a dead end? This is how institutional knowledge compounds. If you built a voice interface for the prototype, the patterns from our Build a Voice Assistant for Your Terminal guide might be exactly the foundation another FDE needs next week.

The Internal Retro

Spend 30 minutes Friday afternoon writing a “Pattern Report.” If you solved a recurring problem—like extracting structured data from messy logs—capture the approach. These reports become the playbooks that let your team move faster next quarter.

Comp, Career Context, and When to Walk Away

Let’s talk numbers, because the weekly workflow is directly tied to how FDEs are valued. FDE roles at top-tier AI companies command total compensation in the $200K–$400K+ range, with the upper end often including significant equity. The reason is simple: an FDE who can reliably ship a high-signal prototype in one week closes deals that a sales team alone cannot.

The weekly cadence is also your best defense against burnout. If you’re three weeks into an engagement and haven’t shipped a demo, the project is either over-scoped or the customer isn’t serious. The weekly workflow forces the conversation: either we cut scope to fit a week, or we admit this isn’t a prototype, it’s a consulting engagement, and it needs different resourcing.

FAQ: The FDE Weekly Workflow

Q: What if the customer can’t provide data by Monday EOD? A: The week resets. You don’t start coding without data. Politely tell them you’ll be ready to kick off the Monday after their data lands. This protects your time and signals that you’re a scarce resource.

Q: How do you handle security reviews that slow down access? A: Build against synthetic or scrubbed data locally first. Show the demo with synthetic data on Thursday. The moment they see it working, the urgency to clear your access magically increases. This is a core tactic from our Case Study: Deploying an LLM Feature at a Risk-Averse Enterprise Customer.

Q: What tools are in your default FDE backpack? A: A Python environment with litellm (for model switching), streamlit (for instant UIs), lancedb (for local vector search), and ffmpeg (for any media extraction). Plus a personal library of one-liners for the common horrors: encoding detection, JSON repair, PDF text extraction.

Q: Is the weekly workflow documented anywhere as a PDF or template? A: Many FDEs maintain personal Notion or GitHub templates. The core principle—scope Monday, build Tuesday-Wednesday, demo Thursday, package Friday—is the standard. The specific templates evolve with your tooling.

Q: How do you handle a demo that fails live? A: Don’t panic. Narrate what you’re checking. “Looks like this record has an unexpected encoding—let me add a handler for that right now.” Fix it live. That 90-second fix is worth more than 10 flawless demos. It proves you can handle their real-world mess. For more on operating without full access, see our playbook on Debugging in the Dark: How FDEs Solve Customer Issues Without Environment Access.