Scaling Yourself: When an FDE Should Hand Off a Prototype to Core Engineering

The FDE Bottleneck Paradox

You just shipped a prototype that unblocked a $2M deal. The Slack love is raining down. Sales wants it in every new pitch. The customer is asking for "just one more feature." You are the hero. And you are about to become the single point of failure.

The Forward Deployed Engineer role is defined by speed and customer intimacy. You live in the gap between a signed contract and a production-ready feature. But the prototype that wins the deal is rarely the code that should live in the core product for five years. Knowing when to hand it off to Core Engineering is the difference between a senior FDE who scales the business and a mid-level one who burns out maintaining a graveyard of bespoke microservices.

This playbook is a decision framework for that handoff. No vague advice. We'll cover the exact triggers, the artifact you need to produce, and the social engineering required to make the handoff stick.

The Three Handoff Triggers

You don't hand off based on a calendar date. You hand off based on signals. There are three hard triggers. If one fires, you start the process.

1. The "Second Customer" Trigger

You built a custom ingestion pipeline for Acme Corp's legacy SAP system. It works. Now Beta Inc. wants the same thing, but their schema is slightly different.

Your instinct will be to fork the repo, add a few if statements, and call it a day. Resist this. The moment a second customer asks for a capability, it is no longer a one-off prototype. It is a nascent product feature. If you fork it, you have just created two snowflakes that will diverge and consume your nights.

Action: When Customer B raises their hand, initiate the handoff conversation. The prototype has proven product-market fit for a specific vertical.

2. The "Operational Load" Trigger

You are spending more time on-call for your prototype than building new prototypes. The thing crashes every Tuesday at 3 AM because a cron job runs out of memory. You're manually SSHing into a box to truncate a table.

FDEs are not SREs. Your hourly rate (billable or internal cost-center) is justified by closing revenue gaps, not by baby-sitting a Node.js process. If the operational burden crosses 4 hours per week, you are losing money for the company.

Action: Track your time for two weeks. If "maintenance" exceeds 20% of your capacity, it's a hard trigger.

3. The "Security/Compliance" Trigger

Your prototype probably uses a long-lived API key hardcoded in a .env file. It likely logs raw customer PII to stdout. That was fine for a proof-of-concept demo. It is not fine for a Fortune 500 production environment.

When the customer's security team starts asking for SOC2 reports, SAML SSO, or audit logs, you must hand off. You cannot retrofit enterprise security on a Flask app in a weekend.

Action: The first security questionnaire from a customer is the trigger. Forward it to Core Engineering along with the repo.

The Handoff Readiness Checklist

Core Engineering teams are allergic to "tossed over the wall" prototypes. If you hand them a messy script, they will rewrite it from scratch, wasting your effort. To ensure your code is adopted, it must meet a minimum bar.

Before you schedule the handoff meeting, verify these four items:

The ADR is non-negotiable. Core Engineers weren't in the customer meetings. They don't know why you chose DuckDB over Postgres. They will judge your choice harshly unless you explain the constraint (e.g., "The client's air-gapped environment had no network access, so embedded DuckDB was the only option").

The Technical Handoff Artifact

Don't just send a Slack message saying "repo is ready, bye." You need a structured artifact. This is a living document, but we often write it as a HANDOFF.md in the root of the repository.

Here is the template:

# Handoff: [Feature Name]

## 1. Business Context
- **Customer(s):** Acme Corp, Beta Inc.
- **Contract Value at Risk:** $X ARR
- **Problem Solved:** Replaced manual CSV uploads with real-time API sync.

## 2. Technical Architecture

3. Known Limitations (The "Scary" Section)

• Memory Leak: The Python bridge holds connections open if the Oracle server closes unexpectedly. Current fix: a cron job restarts it nightly.
• No Auth: Relies on IP whitelisting. Needs OAuth2 for GA release.

4. Customer Promises Made

• We committed to 99.9% uptime SLA starting Q3.
• We committed to adding incremental loading by September.

5. Key Contacts

• Customer Sponsor: Jane Doe (jane@acme.com) - Expects weekly updates.
• Sales Lead: John Smith

Notice the **"Scary" Section**. Be radically transparent about the hacks. If you hide the memory leak, Core Engineering will find it at 3 AM and never trust you again. Explicitly listing them shows maturity and saves them debugging time.

## The Social Contract: You're Not Dumping

Handoff fails not because of technical reasons, but because of social ones. Core Engineers have their own roadmap. Your prototype is an unplanned interruption.

You need to sell the handoff internally just like you sold the prototype externally.

**The Pitch:**
"I have a working solution that is already generating $X in revenue. I've done the messy discovery work. I am handing you a validated specification written in code, not a vague Jira ticket. I need you to industrialize it so I can go close the next $X deal."

**The Commitment:**
You must offer a **20% Shadow Period**. For the first sprint after handoff, you are available for 20% of your time to answer questions, review PRs, and introduce them to the customer. This derisks the transition for the Core team and ensures they don't revert to a "rewrite everything" mentality out of fear.

## Post-Handoff: The 20% Shadow

During the shadow period, your goal is to delete your own access.

1.  **Pair on the first PR:** Don't just review it; sit down and write the first production commit with the Core Engineer who inherits the code.
2.  **Transfer the customer relationship:** Introduce the Core PM to the customer sponsor. Explicitly say, "Sarah is taking over the technical ownership. She's smarter than me." You must transfer trust.
3.  **Define the "Done" state:** The handoff isn't done when the repo is transferred. It's done when the Core team deploys the feature to production for the customer without you on the call.

## Comp and Career Implications

Why do FDEs fail to hand off? Fear. They fear that if they give away the code, they give away their job security.

The opposite is true. At the Staff+ level, your value is not measured by lines of code you own, but by revenue you unlock.

If you are maintaining 5 prototypes, you are a Senior FDE (comp range: $180k-$220k + equity).
If you have handed off 5 prototypes that became core product lines generating $10M+ in ARR, you are a Principal FDE or Head of FDE (comp range: $250k-$350k + significant equity).

Your code is a liability. Your ability to scale yourself through the engineering organization is the asset. Handing off is how you get promoted.

**Related Playbooks:**
- For another example of building a prototype that might eventually need a handoff, see how we built a [Discord Community FAQ Bot Backed by Your Docs Using Supabase and OpenRouter](/blog/build-discord-faq-bot-backed-by-docs-supabase).
- The handoff conversation often starts right after the sale closes. Understand the upstream workflow in [How FDEs Work with Product and Engineering After the Sale Closes](/blog/fde-work-with-product-eng-after-sale).
- If your prototype involves complex log analysis, the principles in [Build an On-Call Incident Summarizer That Reads Logs and Drafts a Postmortem with Gemini](/blog/build-on-call-incident-summarizer-postmortem-gemini) apply directly to the "Operational Load" trigger.

---

## FAQ

**Q: What if Core Engineering refuses to take the prototype?**
A: This is a prioritization conflict. Escalate to your VP. Frame it as a revenue risk: "We have $X ARR dependent on a Python script with no auth. If we don't industrialize it, we lose the renewal." If the business decides to accept the risk, get that decision in writing. You are not the fall guy.

**Q: How clean does the code really need to be?**
A: Clean enough that a tired engineer on a Friday afternoon can understand the control flow without calling you. It doesn't need to be beautiful. It needs to be legible.

**Q: Should I learn the core stack to make the handoff easier?**
A: No. Write the prototype in the language you are fastest in (Python, TypeScript). The Core team will rewrite the critical paths in Go/Rust/Java anyway. Your goal is to provide a running specification, not a merged commit.

**Q: What if the customer demands a feature *during* the handoff?**
A: Do not add it to the prototype. Ask the Core PM to add it to their backlog. You are freezing the prototype scope. Every new feature added during the shadow period resets the clock and creates a moving target.