Scaling Yourself: When an FDE Prototype Becomes a Core Engineering Handoff

The FDE Handoff Trap

You shipped a prototype in three days that a customer now depends on. The code is held together with environment variables and optimism. Then your calendar gets the invite: "Integration Architecture Review." A staff engineer wants to productionize your work.

This is the moment most Forward Deployed Engineers stumble. Not because the code is bad—because the handoff was never designed. You built for speed. Core engineering builds for scale. The gap between those two postures is where prototypes die, careers stall, and customers get frustrated.

The good news: this transition is predictable. Once you see the pattern, you can engineer the handoff as deliberately as you engineered the prototype. This playbook covers exactly how.

Stage 1: The Prototype That Worked Too Well

Let's ground this in a real scenario. You're an FDE at a company selling an AI inference platform. A financial services customer needs to classify 10,000 support tickets per hour using a fine-tuned model. Their existing pipeline is a mess of Airflow DAGs and manual review queues.

You build a prototype in 72 hours:

• A Python FastAPI service wrapping their model
• A Redis queue for batching requests
• A 200-line React dashboard showing classification confidence scores
• Webhook callbacks to their internal ticketing system

The customer loves it. They're running 500 tickets/hour through it. Your Account Executive is already talking expansion.

Then the core platform team hears about it. They see:

• No authentication beyond a hardcoded API key
• Zero retry logic on the webhook delivery
• The Redis instance is a single-node dev container
• The dashboard has no access control
• The model loading happens synchronously at startup with no health check

None of this is wrong. You optimized for signal, not production readiness. But now that signal exists, the work needs to move. Your job isn't to become the permanent owner of this service—it's to hand it off without breaking what already works.

Stage 2: Recognizing the Handoff Signals

Not every prototype graduates. Pushing everything to core engineering is a fast way to lose trust. You need a framework for deciding what qualifies.

Signals a prototype should become a core feature:

Signals a prototype should stay with you:

• Single-customer, one-off integration with no roadmap for reuse
• Experimental feature where the customer is explicitly in a design partnership
• Work that depends on customer-specific infrastructure you're the only one with access to

The worst outcome is handing off something that core engineering doesn't want and can't maintain. Before you write a single line of handoff code, verify with the receiving team that they have appetite and capacity.

Stage 3: Architecting for Handoff, Not Just for Now

Here's where most FDEs go wrong: they hand off the prototype as-is and expect core engineering to "just clean it up." That's not a handoff—it's a dump.

You need to restructure the work into two layers:

Layer 1: The Platform-Grade Core (what core engineering takes)

This is the functionality that should live in the main product. For our classification service example:

• The model serving interface
• The batching and queueing logic
• The webhook delivery mechanism with retry policies
• The API authentication layer

Layer 2: The Customer-Specific Shim (what you retain)

This is the glue that makes the core work for your specific customer:

• Their custom preprocessing logic for ticket text
• The dashboard with their branding and specific metrics
• Integration adapters for their particular ticketing system version
• Their specific alert thresholds and notification channels

The handoff contract is: core engineering owns Layer 1. You continue to own Layer 2 until it becomes generic enough to absorb, or the customer's success team can manage it.

This split is the single highest-leverage move in the handoff. It gives core engineering a clean interface. It keeps you in the loop for customer-specific logic that only you understand. And it creates a natural boundary where future customers' needs can be absorbed into the platform incrementally.

Stage 4: The Non-Code Assets That Matter More

Documentation is table stakes. The assets that actually make a handoff succeed are the ones most engineers skip.

The Decision Log

A markdown file in the repo called DECISIONS.md that records every non-obvious choice you made:

## Why Redis instead of RabbitMQ
Customer's infra team already managed Redis clusters.
RabbitMQ would have required a new operational burden they
pushed back on during scoping. If we move to multi-tenant,
revisit this.

## Why synchronous model loading at startup
Their model is 200MB. Lazy loading added 3s to first request
latency, which violated their SLA. If model size grows past
1GB, we need a different strategy.

## Webhook timeout set to 30s
Their ticketing system occasionally takes 20s+ to acknowledge.
We tuned this with their SRE team on 2024-11-14. Do not lower
without re-testing.

This document prevents the core team from "fixing" things that aren't broken and reintroducing constraints you already solved for.

The Customer Context Brief

A one-pager covering what the receiving engineers need to understand about the customer:

• Their technical constraints (what they can and can't run)
• Their key stakeholders (who screams when this breaks)
• Their success metrics (what numbers they report to their VP)
• Their deployment process (how code actually reaches production in their environment)

The Operational Runbook

What to do when things go wrong. Include:

• Common failure modes you've already hit
• Who to contact on the customer side for each class of problem
• Rollback procedures
• Monitoring dashboards and what "normal" looks like

If you've been doing FDE work for any length of time, you've learned that the highest-leverage skills aren't just technical. Communication artifacts like these are what separate a smooth handoff from a multi-month slog.

Stage 5: The Actual Handoff Meeting

This is not a status update. It's a deliberate transfer of ownership. Structure it in three phases:

Phase 1: Context Setting (15 min)

• Why this prototype exists and what problem it solves
• The customer's business context (from the Customer Context Brief)
• What's at stake (revenue, relationship, renewal timeline)

Phase 2: Technical Deep Dive (45 min)

• Walk the Layer 1 / Layer 2 split diagram
• Review the decision log, focusing on the 3-5 most surprising choices
• Live code walkthrough of the critical path (model serving → batching → webhook delivery)
• Point out the sharp edges: "This regex fails on tickets with embedded JSON" or "The Redis connection pool leaks under >1000 concurrent requests"

Phase 3: Ownership Transfer (30 min)

• Explicitly state what you're handing off and what you're retaining
• Define the escalation path: when should they pull you back in?
• Set a 30-day check-in to review how the handoff is holding up
• Create the shared Slack channel or Jira component for ongoing coordination

The meeting ends with a written summary that both teams acknowledge. No ambiguity about who owns what.

FAQ

What is the FDE salary?

FDE compensation varies significantly by company stage and model. At top-tier AI companies (Anthropic, OpenAI, Databricks), total compensation for experienced FDEs typically ranges from $200K–$400K+, with a heavier equity component at earlier-stage companies. Enterprise SaaS companies hiring FDEs often land in the $180K–$280K range. The premium over a similarly-leveled pure software engineer is typically 15–30%, reflecting the customer-facing and travel demands of the role.

What is the salary range for an Anthropic forward deployed engineer?

Based on publicly available data, Anthropic FDE roles have been posted with base salary ranges of approximately $250K–$385K, with total compensation including equity and bonuses pushing the upper end significantly higher. These roles are highly competitive and typically require demonstrated experience shipping AI systems into production environments with enterprise customers.

Is a forward deployed engineer a good job?

For the right person, it's one of the highest-growth roles in engineering. You get exposure to business strategy, customer problems, and technical architecture simultaneously. The tradeoffs are real: travel can be significant (20–40% at some companies), the context-switching is intense, and you'll occasionally feel stretched between engineering and go-to-market expectations. If you thrive on variety, autonomy, and seeing your code create immediate customer value, it's hard to beat. For a ground-level view of the work, see what an FDE actually does in a week.

What is the average salary for a forward deployed engineer at Databricks?

Databricks FDE compensation typically ranges from $180K–$320K total compensation depending on level and location. The role at Databricks is well-established (they effectively pioneered the FDE function) and includes significant equity upside. Levels.fyi and Glassdoor provide current, self-reported data points that are worth checking for the most recent figures.

How do I prepare for the handoff conversation with core engineering?

The most important preparation is having the Layer 1 / Layer 2 split clearly defined before the conversation starts. If you walk in with "here's my prototype, please take it," you'll get resistance. If you walk in with "here's the platform-grade core I've identified, and here's what I'll continue to own," you're offering a clean contract. The decision log and operational runbook from Stage 4 are your supporting evidence that you've done the thinking.

What if core engineering refuses the handoff?

This happens. Common reasons: they're understaffed, the prototype doesn't align with their roadmap, or they don't trust the code quality. Your recourse is to make the maintenance cost visible to your own leadership. If you're spending 15+ hours a week on a prototype that's generating revenue, that's a resourcing conversation, not a technical one. Escalate through your manager with data, not complaints.

How long should a handoff take?

For a prototype of moderate complexity (what you'd build in 3–5 days), a clean handoff should take 1–2 weeks of part-time work. That includes writing the decision log, restructuring into Layer 1 / Layer 2, creating the runbook, and running the handoff meeting. If it's dragging past three weeks, something is wrong—either the prototype was too coupled to proceed without major rewrites, or the receiving team isn't actually committed to taking it.

Handoffs are a forcing function. They expose whether you built something maintainable or something that only you can operate. The FDEs who scale fastest are the ones who treat the handoff not as an afterthought, but as a design constraint from day one of the prototype.