Scaling Yourself: When and How an FDE Hands Off a Prototype to Core Engineering

The FDE Handoff Problem: Why We Hoard Prototypes

You just shipped a working prototype that solves a $2M customer's critical workflow. The code lives in a repo only you touch, the database schema was designed at 2 AM, and the customer has your personal Slack. The natural instinct is to keep shepherding it—you built it, you understand it, and handing it off feels like abandoning a child in the woods. This instinct is the single biggest bottleneck to FDE leverage.

Forward Deployed Engineers operate on a frontier where speed to customer value is the only currency that matters. You build things that don't exist yet, often against APIs that are still in private beta. But the FDE role is not a permanent product engineering role. It's a scouting function. You prove something is possible, de-risk the technical approach, and then get out of the way so the platform can scale to hundreds of customers.

The data backs this up: top-performing FDEs spend less than 30% of their time on post-prototype maintenance. They treat handoffs as a first-class deliverable, not an afterthought. The ones who don't end up as accidental SREs for a growing graveyard of custom features, watching their bonus multiplier shrink because they stopped shipping new zero-to-one work.

This playbook covers the concrete mechanics: when to pull the trigger, what artifacts to produce, and how to structure the transition so core engineering actually wants to take ownership.

The Hard Kill Criteria: When to Hand Off (and When Not To)

Not every prototype deserves a handoff. Some things you build are tactical one-offs that should be thrown away. Others are the seed of a platform feature that needs to mature. The decision framework below is what I use with every engagement.

The most common failure mode I see: an FDE builds something for a single large customer, it works, and they keep it running for 18 months. The customer is happy, but the FDE has become a single point of failure. When that engineer leaves, the customer is at risk. Hand off before you become the only person who understands the system.

The "Not Yet" Zone

Some prototypes genuinely aren't ready. If the underlying product API is still in alpha and changing weekly, don't hand off—you'll create churn for core engineering that erodes trust. Instead, freeze scope with the customer ("this is working for your current workflow, we'll revisit when the API stabilizes") and document the dependency chain so you're not the only one tracking it.

The Handoff Artifact Stack: What Core Engineering Actually Needs

Core engineering teams are drowning in their own roadmap. When you toss a prototype over the wall with a one-paragraph README, you're asking them to reverse-engineer your intent. That's a recipe for the prototype rotting in a deprecated/ folder.

The artifact stack below is battle-tested. It takes roughly 2-3 days to produce for a complex prototype, and it's the difference between a handoff that gets picked up in a sprint and one that gets ignored for six months.

Artifact 1: The One-Pager (Business Context)

Audience: Product Manager and Engineering Manager. Length: One page, plain English. Must contain:

• What customer problem this solves (with a direct quote from the customer if possible)
• Which accounts are live on it and their ARR
• What happens if we don't productize it (churn risk, competitive gap)
• Rough sizing of the addressable market (how many other customers have this need)

This is not a technical document. It's the "why should we care" document. Without it, your prototype is just code without a constituency.

Artifact 2: The Technical Design Doc (Architecture)

Audience: Staff Engineer and Tech Lead who will own it. Length: 3-5 pages with diagrams. Must contain:

• System architecture (see diagram pattern below)
• Data model and schema decisions (with rationale for why you chose what you chose)
• Known limitations and scaling cliffs ("this falls over at 10k records because of the in-memory cache")
• Security considerations (auth model, data residency, PII handling)

Here's a typical handoff architecture for an LLM guardrails feature I shipped at an enterprise customer:

Artifact 3: The Runbook (Operations)

Audience: On-call engineer at 3 AM. Length: 2-3 pages, heavily bulleted. Must contain:

• How to deploy (exact commands, not "use the CI pipeline")
• Common failure modes and their symptoms
• Escalation path (who knows the system, in order)
• Dashboards and alerts (links, what to look for)
• Rollback procedure

Artifact 4: The Customer Transition Plan

Audience: Customer Success Manager and the customer's technical contact. Length: One page. Must contain:

• Timeline for handoff ("I will be your point of contact until March 15")
• Who they should contact after handoff
• Any behavior changes they should expect ("the API endpoint stays the same, but rate limits will be enforced globally")

The Technical Handoff: Code, Tests, and Architecture

Artifacts are table stakes. The code itself needs to be in a state where another engineer can reason about it without a three-hour walkthrough from you.

Code Quality Baseline

Before handing off, the repo must pass these gates:

1. Tests exist and pass. Not 100% coverage, but the happy path and the top three failure modes are covered. If you don't have tests, write them during the handoff window—it's the fastest way to document expected behavior.
2. Linting and formatting are automated. Nobody wants to inherit a codebase where half the files use tabs and half use spaces. pre-commit hooks or equivalent.
3. Dependencies are pinned. package-lock.json, requirements.txt with hashes, or equivalent. The prototype worked when you built it; don't let a floating dependency break it two weeks after handoff.
4. Secrets are externalized. No hardcoded API keys. Use the company's secret manager, even if it's just a .env.example with clear instructions.

The Walkthrough (Live, Recorded)

Schedule a 60-minute synchronous walkthrough with the receiving team. Record it. Structure it as:

• 15 min: Business context and customer impact (use the one-pager)
• 25 min: Codebase tour (entry points, key modules, where the logic lives)
• 15 min: Live demo against a staging environment
• 5 min: Q&A

The recording matters because the engineer who inherits this might not be hired yet. It's your insurance policy against institutional amnesia.

The Organizational Handoff: Ownership, On-Call, and SLAs

Code without ownership is abandoned code. The handoff isn't complete until there's a named team, a named owner, and a pager that isn't yours.

The Ownership Transfer Checklist

• Team assignment: Which engineering team owns this going forward? (Get this in writing from an EM, not a Slack "sounds good")
• Backlog items created: At minimum, tickets for: (1) productionization hardening, (2) monitoring and alerting, (3) documentation cleanup.
• On-call rotation updated: Your name comes off the escalation path. The receiving team's rotation adds this service.
• SLA defined: What's the uptime expectation? Is this tier-1 (customer-facing, pager-worthy) or tier-2 (internal tooling, can wait until morning)?
• Cost center identified: Who pays for the infrastructure? If it's still on your team's AWS budget, the handoff is cosmetic.

The Gradual Off-Ramp

Don't go from 100% ownership to 0% overnight. A 2-4 week transition where you're available for questions but not the first responder works well. Set explicit expectations: "For the next two weeks, I'll respond to Slack questions within 4 business hours. After April 1, I'm not on the critical path."

The Anti-Patterns: Shadow Engineering and the "Throw It Over the Wall" Fail

Shadow Engineering

This is when you build something, hand it off on paper, but keep maintaining it in practice because the receiving team is too slow or doesn't understand it. The customer keeps coming to you because you're faster. Congratulations: you've created two jobs for yourself, and you're failing at both.

The fix: After the transition window, redirect customer requests to the new owning team. "I'm looping in the platform team—they own this capability now and can serve you better than I can." It feels uncomfortable. Do it anyway.

The "Throw It Over the Wall" Fail

This is the opposite problem: you hand off a prototype with zero context and immediately move on. The receiving team opens the repo, finds 4,000 lines of uncommented Python with a README that says "TODO," and rightfully resents you.

The fix: The artifact stack above. If you don't have time to produce the artifacts, you don't have time to hand off. Negotiate with your manager to carve out the time—frame it as de-risking the customer relationship.

The "Rewrite Everything" Trap

Core engineering teams often want to rewrite a prototype from scratch because "the code quality isn't production-grade." Sometimes they're right. Often, they're underestimating the edge cases you already solved. Push back with data: "Here are the 14 edge cases this code handles. Here are the three production incidents it's survived. A rewrite will take 6-8 weeks and re-learn these the hard way. Can we incrementally refactor instead?"

Career Context: Why Handoffs Are Your Leverage Multiplier

FDE compensation is heavily weighted toward impact, not lines of code. At top-tier companies, FDE total compensation ranges from $180K to $350K+ depending on seniority and equity structure (see FDE Compensation Bands and How to Negotiate Your Offer). The variable that moves you up that band is not how many prototypes you built—it's how many prototypes you built that turned into platform revenue.

A prototype that stays with you generates value for exactly one customer relationship. A prototype that gets handed off and productized generates value for every customer that fits the pattern. Your manager and the VP of Engineering both understand this math. The FDEs who get promoted to Staff and Principal are the ones who treat handoffs as their primary scaling mechanism.

This ties directly into what an FDE actually does day-to-day—if you haven't read the weekly workflow breakdown, What a Forward Deployed Engineer Actually Does in a Week covers the full rhythm.

Handoffs also compound your reputation inside the company. Core engineering teams that receive clean, well-documented prototypes from you will actively seek you out for the next customer engagement. You become the FDE who "doesn't create messes," which means you get staffed on the most interesting problems.

FAQ

Q: How long should a handoff take from start to finish? A: For a prototype that's been running in production with a customer for 4-8 weeks, budget 3-5 working days to produce artifacts, clean up code, and run the walkthrough. The transition period (where you're available for questions) should be 2-4 weeks. If the prototype is less mature, add time for test coverage and documentation.

Q: What if core engineering refuses to take ownership? A: This is an organizational problem, not a technical one. Escalate through your management chain with the business case (the one-pager). Frame it as revenue risk: "If I get hit by a bus, we lose Customer X's $1.2M renewal because nobody else understands this system." If the company won't staff it despite clear business impact, that's a signal about how the company values the FDE function.

Q: Should I hand off code that I know is ugly? A: Yes, but be honest about it. The technical design doc should have a "Known Technical Debt" section. Call out the ugly parts explicitly: "The rate-limiting logic in limiter.py is a hack that works for <100 req/s but needs a rewrite for scale." This builds trust—the receiving team knows you're not pretending it's perfect.

Q: What's the difference between an FDE handoff and a solutions architect handoff? A: Solutions architects typically hand off designs and configurations, not production code. FDEs hand off working software that's already serving customer traffic. The artifact stack is similar, but the FDE handoff includes operational responsibility transfer (on-call, SLAs, cost) that SA handoffs rarely touch.

Q: How do I handle a customer who only trusts me and resists the handoff? A: Bring the new owning engineer into a customer call before the handoff completes. Introduce them as "the engineer who's going to make this feature even better." Do a joint debugging session. The customer needs to see a face and build trust with a new person. If you disappear without a warm introduction, the customer will find you on LinkedIn and DM you anyway.