The Prototype Is Not the Product

Code written to validate a thesis in week one, under time pressure, with hard-coded assumptions about a specific test environment, is rarely the code that should run unattended in production. Budget real time — often as much as the original build — for a deliberate rewrite pass focused on the things a pilot doesn't need but production does: error handling for every external call, monitoring and alerting, graceful degradation when a dependency is slow or down, and configuration that doesn't assume the FDE's laptop is always the one running it.

Skipping this step to hit a deadline is the single most common cause of a pilot that looked great and then quietly degraded, or broke outright, once the person who understood its rough edges stopped watching it daily.

Documentation That Survives Staff Turnover

The person who receives your handoff documentation today may not be the person maintaining the system in eight months. Effective handoff documentation assumes the reader has none of the context you built up over the engagement:

  • An architecture overview written for someone seeing the system for the first time — what calls what, where data flows, where the model provider sits in the chain.
  • A runbook for the failure modes you actually saw during the engagement, not a generic template — what alert fires, what it usually means, and the first three things to check.
  • The evaluation set and its results from Article 7, so the receiving team has a concrete baseline to compare against if they suspect the system's quality has drifted.
  • An explicit list of known limitations — the edge cases the system doesn't handle well, stated plainly rather than left for the receiving team to discover in production.
Name an owner for prompt and model changes

This is the single most commonly missed item in handoffs. Infrastructure gets a named owner almost automatically because it's familiar territory to an IT team; prompts, retrieval configuration, and model version upgrades often don't, because they don't look like "real" infrastructure to teams new to AI systems. Without an explicit owner and an explicit change-review process, these components drift silently — a well-meaning edit to "improve" a prompt six months later, untested, is a common source of regressions nobody traces back to its cause.

Transferring Operational Knowledge, Not Just Code

A repository handed over with a README is necessary but not sufficient. The deeper transfer is operational: walking the receiving team through a real incident from the engagement — what broke, how you noticed, what you tried, what fixed it — teaches pattern recognition that no document fully captures. Where the schedule allows, shadow the receiving team running the system for a week before you're fully off the engagement, rather than disappearing the day after a handoff meeting.

Defining the Ongoing Relationship

Handoff isn't necessarily the end of the FDE's involvement — it's a change in the shape of it. Set explicit expectations before the engagement winds down: is there a support window where the FDE remains reachable for escalations, and for how long? Who approves changes to the evaluation set or success metrics going forward? Is there a scheduled review — 30, 60, 90 days out — to check the system is still performing as expected in the customer's hands? Leaving this ambiguous is how engagements that ended well quietly become engagements nobody can get a straight answer about a year later.

The 30-Day Check-In

A short, scheduled follow-up 30 to 60 days after handoff is disproportionately valuable relative to its cost. By then the receiving team has hit the real edges of the system — the questions that seemed clear in the handoff meeting but turned out to be ambiguous in practice. Asking directly what's confusing or what's broken, while there's still enough shared context between both sides to fix it quickly and cheaply, prevents small gaps from calcifying into larger, harder-to-diagnose problems.

Signs a Handoff Isn't Actually Done

  • The receiving team routes every question back to the FDE instead of consulting the documentation — a sign the documentation doesn't actually answer the questions that come up.
  • Nobody on the customer side can explain, in their own words, how the retrieval or evaluation pipeline works — a sign the walkthrough didn't transfer real understanding, just familiarity with the demo.
  • Alerts exist but nobody is confirmed to be watching them — ownership of monitoring needs a name attached, not an assumption.
  • The evaluation set from Article 7 isn't scheduled to be re-run periodically — without it, quality drift is invisible until a user complains.

Frequently Asked Questions

Should the prototype code ever ship to production as-is?
Almost never, and treating this as an option is a common mistake. Prototype code is optimized for speed of iteration, not for the error handling, monitoring, and maintainability a production system run by someone else needs. Budget real time for a rewrite once the pilot has validated the approach.

How do you prevent a handoff from silently failing months later?
Schedule a check-in 30 to 60 days after handoff, not just a handoff meeting and silence. Ask the receiving team directly what's confusing or breaking, while there's still enough shared context to fix it quickly. Silence after handoff is not the same as success.

What is the single most commonly missed item in a handoff?
A clear owner for ongoing model and prompt changes. Engineering teams often document infrastructure thoroughly but leave unstated who decides when a prompt needs updating, who approves the change, and how it gets tested before going live — which causes drift and unowned risk within a few months.