From Customer Handoff to Working Prototype: The FDE's First Week Sprint

The Forward Deployed Engineer (FDE) role collapses the traditional distance between a vendor's engineering team and a customer's production environment. You aren't just an implementation consultant documenting gaps; you are a temporary, embedded CTO who writes code against live customer systems. The first week is the most high-stakes sprint of the engagement. It sets the technical trajectory, establishes trust, and determines whether the proof-of-concept is a disposable slide deck or a kernel of production infrastructure.

This playbook breaks down the exact workflow, from the initial customer handoff to a working prototype, using real scenarios, tactical decision frameworks, and the tools that actually ship.

The Handshake: From Sales Pitch to Engineering Reality

Before you open an IDE, you must triage the handoff from the sales or solutions team. The sales deck promised a magical integration; your job is to find the engineering seams.

The 3-Document Rule Never accept a verbal handoff. Insist on receiving—or creating—three artifacts before Day 1:

1. The Technical Scoping Doc: A one-pager listing the customer's tech stack, expected data volumes, and the exact API endpoints or database tables you'll touch.
2. The Success Criteria: Defined in binary terms. "Improve efficiency" is useless. "Reduce manual data entry for the reconciliation workflow from 4 hours to under 10 minutes" is an engineering target.
3. Access Credentials: Staging environment API keys, a VPN configuration, and read-only database credentials. If you don't have these by the end of the handoff call, Day 1 is dead on arrival.

The Red-Flag Detector During the handoff, listen for the "magic integration" assumption. If the customer says, "We just assumed your tool would plug into our legacy AS/400 mainframe," you must immediately reset expectations. The prototype will almost certainly require a lightweight middleware adapter or a flat-file drop—clarify this before the clock starts.

Day 1: Environment Recon and the 'Hello World' of Customer Data

The goal of Day 1 is not to build features. It is to prove connectivity and understand the shape of the data. You want a "Hello World" running in the customer's environment, not yours.

The Local-to-Remote Bridge Start by cloning the customer's staging setup locally. If they use Docker, get their docker-compose running. If they don't, ask for a curl command that proves you can hit their internal API.

A common Day 1 pattern for an AI-centric FDE engagement looks like this:

Tooling Stack for Day 1

• jq and csvkit: For quickly inspecting JSON payloads and CSV exports without writing boilerplate parsers.
• ngrok or Cloudflare Tunnel: If the customer needs to hit a webhook but their firewall isn't open yet, expose your local port immediately.
• Streamlit or Gradio: Not for the final product, but to wrap your first successful API call in a UI the customer can click by the end of the day. A button that says "Fetch Recent Orders" and returns a table builds more trust than a terminal log.

The First Commit Push a README to a shared repository documenting exactly how you authenticated. This is your insurance policy. If you get locked out on Day 3, you have a reproduction script.

Day 2: The Architecture Sketch and the 'Ugly Prototype'

With connectivity proven, you now face the core technical decision: what is the minimal slice of functionality that demonstrates the value proposition?

The Traction Protocol Don't build the full pipeline. Identify the "happy path" where the input data is clean and the output is impressive. If the engagement is about automating a legal document review, don't start by handling 50 file formats. Hard-code the path to one clean PDF, run it through the core logic (e.g., a screenshot-to-code agent or a custom extraction prompt), and display the result.

The Ugly Prototype Manifesto An FDE's prototype must be ugly but functional. Use hard-coded strings. Ignore pagination. Write a 200-line Python script with global variables. The purpose is to fail fast on the logic, not to win a code review. If the core algorithm is wrong, beautiful abstractions are wasted code.

Handling the "Hairball" Integration Often, the customer's data isn't in a clean API. It's in a tangled SFTP server or a web scraping requirement. For rapid extraction, a receipt-to-JSON extractor pattern using a vision model often works better than brittle XPath selectors. Point a vision model at the legacy report screenshot and extract the data as structured JSON. It's not production-grade, but it's a week-1 prototype that proves data can flow.

Day 3: The Hardest 20%: Authentication, Permissions, and Edge Cases

Day 3 is where the prototype transitions from a demo to a working tool. This is the day you fight the enterprise.

The Auth Quagmire You will encounter OAuth2 flows that require manual browser intervention, or API keys that rotate every hour. Your job is to encapsulate this ugliness behind a single function. Write an authenticate() method that returns a bearer_token, even if it currently requires a manual copy-paste step. This isolates the enterprise complexity so the core logic remains testable.

The Data Quality Shock Run your Day 2 script against a broader dataset. You will discover null fields, duplicate records, and encoding errors. This is the moment to define the error contract. Don't silently drop bad rows. Log them to a quarantine.csv file and flag them in the UI. The customer needs to see the data quality issues to understand the scope of the production build.

The Compliance Check If you are handling PII (Personally Identifiable Information), Day 3 is the deadline for a quick sanity check. Are you logging raw data? Are you sending sensitive text to external LLM APIs without redaction? For a codebase Q&A tool, for example, the RAG pipeline must filter out secrets before indexing. A prototype that leaks data is a fired FDE.

Day 4: The 'Wow' Moment: Packaging and User Feedback

By Day 4, the script works. Now you make it feel like a product the customer can actually use.

The 10-Minute UI Rule Using Streamlit, Gradio, or a simple Flask template, wrap your script in an interface that the specific user persona can navigate. If the end user is a supply chain manager, don't give them a Swagger docs page. Give them a file upload button and a "Generate Report" button.

The Feedback Loop Schedule a 30-minute synchronous session with the actual end user (not just the executive sponsor). Watch them click. You are looking for the "silent confusion" moment—the hesitation before a click. Every moment of hesitation is a missing label or a broken mental model in your UI.

The "Production Mode" Toggle Add a --env=staging vs --env=production flag to your script. Even if production isn't ready, showing the customer that the path exists changes the conversation from "Can we build it?" to "When do we turn it on?"

Day 5: The Handoff: Production Path and the Technical Memo

The final day is about leaving a trail that an internal team or a longer-term FDE engagement can follow.

The Technical Memo (Not a Wiki) Write a single Markdown document that covers:

1. Architecture Decision Records (ADRs): Why you chose Server-Sent Events over WebSockets, for example.
2. Known Limitations: "This script breaks if a single order has more than 500 line items due to a memory constraint in the current chunking logic."
3. Production Hardening Checklist: A bullet list of exactly what needs to change (e.g., "Replace hard-coded SQL with parameterized queries," "Add Redis caching layer").

The Cost Projection If your prototype uses external APIs (LLMs, SERP APIs), provide a back-of-the-envelope cost estimate. A multi-agent research brief tool might cost $0.12 per run in prototyping but needs a caching layer to stay under $500/month at scale. This is the business context that makes you an FDE, not just a coder.

The Handoff Ceremony Run the prototype live one last time. Record it. Walk through the code repository. Then, explicitly hand over the three artifacts: the running code, the technical memo, and the access credentials. The engagement ends when the customer's internal engineer can run the script from their own machine.

FAQ: First Week FDE Sprint

What if I can't get access to the customer's environment by Day 1? Do not sit idle. Ask for a sanitized data export (CSV or JSON dump). Build the core logic against that static file. When access finally comes through, you only need to swap the data source layer. This is the difference between a blocked engineer and a resourceful FDE.

How do I handle a customer who insists the prototype must look production-ready? Educate them on the "Ugly Prototype" trade-off. Explain that spending 4 hours on CSS is 4 hours not spent finding the edge case that breaks the integration. If they push back, offer a compromise: a clean UI wrapper around a hard-coded backend. The wrapper satisfies the aesthetic need; the hard-coded backend preserves engineering velocity.

When should I say "no" to a feature request during the sprint? Use the "Sprint Goal Filter": if the request doesn't directly contribute to the binary success criteria defined in the handshake, it goes into the "Phase 2" bucket. Your job is to ship the success criteria, not to clear the customer's entire backlog.

Is it normal to feel like I'm writing "throwaway" code? Absolutely. The first week's code is a probe, not a foundation. The insights you gather from the customer's data and feedback are the real deliverables. The code proves the concept; the memo captures the knowledge. For a deeper look at how this cadence fits into the broader role, see What a Forward Deployed Engineer Actually Does in a Week.

How do I prepare for the high-ambiguity nature of this work? The highest-leverage skills are rapid data preparation, precise prompting, and pragmatic modeling. You don't need to know every framework, but you must be able to shape messy data into a structured output fast. We've broken down the core competencies in The Highest-Leverage Skills for an FDE in the AI Era.