On AI MVP handoff day, a non-engineer founder should be able to count eight named artifacts, point at where each one lives, and walk a fractional CTO through them in 45 minutes. If they cannot, the partner ran a build, threw a Git URL over the wall, and called it shipped. This is a buyer’s guide to the handoff window — the eight artifacts a serious AI MVP partner produces at engagement close, what each one proves, and what hand-wave looks like.
This piece sits under the founder-AI-partner operating manual, part of the idea-to-product manifesto. The manual frames the 12-week rhythm; this piece walks the closing window — the line between a product the founder can operate and one that quietly degrades the moment the partner stops paying attention.
Table of Contents
- Why the handoff is the test, not the finish line
- The 8 artifacts you should receive on handoff day
- Artifact 1 — Source code repo
- Artifact 2 — Eval set + runner
- Artifact 3 — Prompt library
- Artifact 4 — Deployment config
- Artifact 5 — Observability dashboard
- Artifact 6 — Runbook
- Artifact 7 — On-call schedule
- Artifact 8 — 30-day support plan
- What hand-wave looks like across all eight
- The day-90 test
- Frequently Asked Questions
- Closing
Why the handoff is the test, not the finish line
The handoff is where most AI MVP engagements quietly fail. The demo works. The contract is paid. Three months later the founder discovers the model bill doubled, two prompts silently regressed, and nobody can answer why because the eval suite was never wired into CI.
BCG’s From Potential to Profit with GenAI finds only about 26% of organizations move past pilots and capture meaningful value, and McKinsey’s State of AI concentrates the production gap in the top quartile that invests in eval discipline, observability, and clear ownership. The handoff window is where that discipline either transfers to the buyer or evaporates.
A bad handoff is invisible at the demo. The product works. The founder signs off. The cost shows up at day 60. A good handoff is one the founder can audit on day one — eight artifacts on a page, each runnable, readable, and owned.
The 8 artifacts you should receive on handoff day
A serious AI MVP handoff produces these eight artifacts. Each one is a file or a system the founder can open without the partner present.
| # | Artifact | What it is | Why it matters |
|---|---|---|---|
| 1 | Source code repo | Git repo on the founder’s org, main branch green, CI passing | The product itself, owned by the buyer |
| 2 | Eval set + runner | Runnable eval suite with rubric, threshold, CI hook | Defines “working” after the partner is gone |
| 3 | Prompt library | Versioned directory of named prompts with eval coverage | Product behavior lives in prompts, not code |
| 4 | Deployment config | Terraform / Pulumi / Docker Compose / Vercel config | A CTO can rerun a deploy six months later |
| 5 | Observability dashboard | Five named queries on real production traffic | Catches drift before the next bill |
| 6 | Runbook | Operator-grade doc with named symptoms and fixes | The founder can triage at 11pm without paging |
| 7 | On-call schedule | Names, hours, paging tool, SLA | Day-89 still has a human at the other end |
| 8 | 30-day support plan | Support window with eval-pass-rate gates | Support ends when quality holds, not on a calendar |
Not on the list: a slide deck, a “vision document,” a Notion wiki, a one-time cloud-console deploy, or a Loom video in place of a runbook. Those are decoration. A partner who substitutes any of them is signaling that the artifact is not coming.
Artifact 1 — Source code repo
A Git repo on the founder’s GitHub or GitLab organization (not the partner’s). Main branch green. CI runs lint, unit tests, and the eval suite on every PR. The README explains how to run the project locally in under fifteen minutes — fresh laptop, clone, env file, a single make dev. Secrets live in a managed vault. The companion guide how AI development partnerships handle IP and code ownership covers the contract side.
Hand-wave looks like: a repo still on the partner’s org with a “we will transfer it” promise. A red main branch. A README that reads “see Slack.” Secrets committed to history. CI that skips the eval suite.
Ask on handoff day: “Show me a green CI run on main from this morning, and the last failed run with the PR that fixed it.”
Artifact 2 — Eval set + runner
A runnable eval suite — Promptfoo, LangSmith, Braintrust, Inspect, or a hand-rolled Python harness — the founder can execute with one command. It covers every named task in the product’s taxonomy, with rubric, threshold, and a pass/fail or 1-to-5 grade per case. Cases use the founder’s domain data, not generic benchmarks. CI runs it on every PR and blocks merge below threshold.
This is the contract that defines “working” after the partner walks away. Without it, the founder has no answer when a model release changes behavior or a prompt edit silently regresses one task. The eval-first build playbook covers how the suite is built during the engagement.
Hand-wave looks like: a Jupyter notebook with twelve cases the partner ran once at the demo. “We tested it” claims with no harness. Eval cases stored in a Notion page, not version control. A pass rate of 100% — which means the rubric is wrong, not the product is perfect.
Ask on handoff day: “Run the suite live against today’s main branch. Show me the pass-rate trend over the last four weeks.”
Artifact 3 — Prompt library
A versioned directory in the repo — usually prompts/ — with one file per named prompt. Each file has a header: prompt ID, owner, last-changed date, eval cases that cover it, model it is pinned to. Prompts are not embedded as string literals inside business logic. Edits go through code review and trigger the eval suite.
Product behavior lives in prompts, not application code. A handoff that ships prompts buried inside controllers prevents the founder from changing behavior without breaking it.
Hand-wave looks like: prompts as string literals across the codebase. A single 2,000-token mega-prompt that does everything. Prompts in a Google Doc, not the repo. No mapping from prompt to eval case.
Ask on handoff day: “Show me the prompt for task T03, the eval cases that cover it, and the last PR that changed it.”
Artifact 4 — Deployment config
Infrastructure-as-code in the repo: Terraform, Pulumi, Docker Compose, Vercel config, or AWS CDK. It provisions every running piece — application servers, database, vector store, eval runner, observability — from a fresh cloud account in under sixty minutes. Secrets come from a managed vault. Two environments exist: production and staging. Deploy is one command.
The test: a fractional CTO joining six months later reads the config and redeploys. If the answer is “they have to call the original engineer,” the handoff is not done.
Hand-wave looks like: a one-time cloud-console setup with no IaC. AWS resources clicked together manually. A .env file with production credentials emailed to the founder. No staging environment. Deploy steps documented in a Loom video.
Ask on handoff day: “Spin up a fresh staging environment in front of me, including the database.”
Artifact 5 — Observability dashboard
A dashboard — Datadog, Grafana, Posthog, Helicone, LangSmith, or hand-rolled — with five named queries running on real production traffic:
- Per-task latency p95 — how slow the slowest 5% of model calls are, per named task.
- Model-call error rate — failures, timeouts, retries, provider 5xx rate.
- Per-active-user cost — daily model spend divided by daily active users, trended week-over-week.
- Eval pass rate on production samples — a daily sample of real traffic re-run against the eval suite.
- Refusal / escalation rate — how often the model refuses, escalates, or hits a guardrail.
These five catch every common AI-product failure mode: latency drift, cost spike, model regression, capability decay, behavioral change. AWS’s ML Lens for the Well-Architected Framework names the same surface. Without these queries, the founder learns about regressions from customers or invoices — both too late.
Hand-wave looks like: a Datadog instance with 80 unnamed widgets. “We log everything to CloudWatch.” A dashboard with no alerts. No cost query. No production-sample eval re-run.
Ask on handoff day: “Walk me through the five queries. Show me the most recent alert and how it was resolved.”
Artifact 6 — Runbook
A markdown file in the repo — RUNBOOK.md — written in the founder’s voice, not the engineer’s. Each section is a named symptom: “Users report wrong answers,” “Model bill spiked overnight,” “The product is slow,” “A prompt edit broke a downstream test.” Each has three parts: confirm (a query or dashboard to check), triage (a one-paragraph diagnosis tree), and escalate (who to call).
A founder-grade runbook means the founder can open it at 11pm and triage without paging anyone. A bad runbook reads as engineer-to-engineer notes — “check the service mesh logs and bounce the prompt cache” — and is useless to the buyer.
Hand-wave looks like: a generic ‘how to deploy’ README labeled “runbook.” A Loom video in place of written symptoms. Engineer jargon with no plain-language symptom names. No escalation path.
Ask on handoff day: “I just got a Slack message from a user saying the product is hallucinating. Walk me through the runbook. I will follow the steps; you watch.”
Artifact 7 — On-call schedule
A page in the repo or a calendar that answers: who pages out when the dashboard fires, what hours they cover, what tool they use, and what SLA they commit to. For a single-engineer partner this is one name; for a studio it is a rotation. The founder leaves handoff knowing the human they call at midnight on day 47.
This artifact is most often missing. Partners say “we are responsive” or “Slack us.” Neither is a schedule. A schedule is “Jane, Mon-Fri 9-6 PT, Opsgenie, 30-minute response, 4-hour resolution for sev-2; after-hours sev-1 only via the on-call rotation paging.”
Hand-wave looks like: “We monitor everything and respond fast.” A schedule that names one engineer with no backup. No after-hours coverage. No SLA tiers.
Ask on handoff day: “If the dashboard alerts at 11pm on a Saturday, who picks up the page? What is the response SLA? Show me the rotation.”
Artifact 8 — 30-day support plan
A scoped support window — usually 30 days, sometimes 60 or 90 — with explicit terms: which artifacts the partner maintains, which fixes are in-scope (bugs, regressions, eval-pass-rate failures) versus out-of-scope (new features, model upgrades), and a fee schedule for post-window work. The crucial detail: the support window is gated on the eval pass rate holding within agreed bounds. If the pass rate drops below threshold, the partner fixes it under the support fee. If it holds, the window closes on schedule.
A calendar-only support window without a quality gate lets the partner ship a regressing product and run out the clock. A quality-gated window aligns the partner’s incentives with the founder’s. The companion piece on post-launch AI support walks the operating side of the window.
Hand-wave looks like: “We support for 30 days, after that it’s hourly.” No quality gate. No definition of “bug” versus “feature.” A handover fee priced after the window — so the founder has no bargaining power.
Ask on handoff day: “On day 14 of the support window, the eval pass rate drops 4 points on the priority-classification task. What happens? Walk me through the contract clause.”
What hand-wave looks like across all eight
Three signatures repeat:
- Loom in place of artifact. A video walkthrough of the system, not a runbook. A demo of the dashboard, not a dashboard URL the founder can open at midnight. Loom is decoration; artifacts are operable.
- Notion in place of repo. Prompts in a Notion page. Runbook in Confluence. Eval cases in a Google Sheet. Anything not in the repo drifts within four weeks and is dead within twelve.
- Calendar in place of contract. A 30-day support window with no quality gate. An on-call schedule that names one engineer with no backup. A handoff “process” that is a single 90-minute meeting with no testable artifacts produced.
Pattern-matching these three at the handoff meeting catches a year of decay in 45 minutes.
The day-90 test
The handoff window is a screening test for the next 90 days. By day 90, a real handoff passes four checks:
- The founder ran a deploy from staging to production without the partner. Once. Even if a fractional CTO did the actual keystrokes — the deployment config worked.
- The eval suite caught one regression in CI. A prompt edit, a model upgrade, a downstream library bump — one event triggered the eval gate and was fixed before merge.
- The cost dashboard surfaced one anomaly. A traffic spike, a runaway loop, an upstream model-tier change — the founder saw it on the dashboard before the invoice.
- The runbook resolved one production symptom without paging the partner. A user reported a real issue; the founder opened the runbook, ran the queries, fixed it.
If all four are true at day 90, the handoff worked. If three of four are not, the handoff was theater.
Frequently Asked Questions
What if the partner produces only six of the eight artifacts on handoff day?
Name the missing two and ask whether they land in five business days. Two missing is recoverable; four or more is not. If the eval suite or the runbook is missing, treat the handoff as incomplete regardless — those two are load-bearing.
Does this list apply to a 6-week MVP, or only larger engagements?
All eight artifacts apply to any AI MVP build. The size adjusts — a 6-week MVP might have 60 eval cases, not 300; 12 prompts, not 40; a 5-symptom runbook, not 15 — but the artifact list is the same.
What does a real AI MVP handoff cost in 2026?
The handoff is not separately priced — it is the closing two weeks of the MVP engagement. A typical idea-to-product engagement runs about $30K planning, $80K MVP build, $40K hardening, with the handoff embedded in hardening. A partner billing a separate $20K “knowledge transfer” fee is double-charging for work the build SOW already covered.
Can I do the handoff myself if I am non-technical?
Yes, with a 4-hour fractional CTO assist. The founder runs the artifact-count audit (“show me each of the eight”); the CTO runs the technical depth check (“is the IaC reproducible, does the eval suite block CI”). Splitting the audit prevents technobabbling past a non-engineer founder.
What if the partner says the eval suite was the build, not the handoff?
That framing is correct — the suite is built during the engagement, not after. The handoff just confirms it is runnable, version-controlled, and wired to CI. If the suite was built but is not in the repo or not wired to CI, the handoff is incomplete.
How does this 8-artifact handoff relate to the day-14 kickoff?
The kickoff produces seven artifacts that scope the build; the handoff produces eight that operate it. The lists share the eval set; the rest differ. See what to expect from your AI MVP partner in the first 14 days for the kickoff list.
What if the partner refuses to gate the support window on eval pass rate?
That refusal is a signal. A partner confident in their build accepts the gate. A partner refusing it either does not believe the pass rate will hold or does not want the accountability. Renegotiate, or move on.
Can the runbook be a Loom video instead of a markdown file?
No. Loom is a useful supplement — record one for the dashboard walkthrough — but the runbook itself is markdown in the repo. Video does not survive search, version control, copy-paste, or being on a plane with bad wifi.
How much of this can a single-engineer partner produce versus a studio?
All of it. A solo senior produces every artifact in this list; the only difference is the on-call schedule names one human with a documented backup arrangement rather than a rotation. The artifact rigor is identical.
Closing
The handoff is the test, not the finish line. Eight named artifacts: source code repo, eval set + runner, prompt library, deployment config, observability dashboard, runbook, on-call schedule, 30-day support plan. Count them on handoff day, ask one question per artifact, run the day-90 test three months later. Related guides — what an AI development partnership actually is and the companion on the anatomy of an AI agency engagement in the first 14 days — sit upstream of this window.
Subscribe to the SFAI Labs newsletter for weekly buyer-side guides to AI MVP engagements.
Arthur Wandzel
