By day 14 of an AI MVP engagement, a non-DIY founder should be able to count seven named artifacts on a single page. If they cannot, the partner sold a discovery sprint and delivered consultancy theater. This is a buyer’s audit guide: the seven artifacts a serious AI MVP partner produces, what each proves, and what hand-wave looks like.
It builds on the founder-AI-partner operating manual, part of the broader idea-to-product manifesto. The manual frames the 12-week rhythm; this piece walks the 14-day screening window.
Table of Contents
- Why the first 14 days are an audit, not an onboarding
- The 7 artifacts you should be able to count on day 14
- Artifact 1 — The PRD draft
- Artifact 2 — The eval set v1
- Artifact 3 — The task taxonomy
- Artifact 4 — The cost model
- Artifact 5 — The capability probe
- Artifact 6 — The weekly cadence agreement
- Artifact 7 — The risk register
- What hand-wave looks like across all seven
- The day-14 review meeting: how to actually run it
- Frequently Asked Questions
- Closing
Why the first 14 days are an audit, not an onboarding
The first 14 days are the cheapest place to discover you hired the wrong partner. McKinsey’s State of AI reports about 78% of organizations use AI in at least one function but few capture measurable EBIT. BCG’s Build for the Future shows only about 26% move past pilots to value. The gap is not the model — it is the discipline of pre-build work.
That discipline is invisible at the SOW stage. You cannot tell from the contract whether the partner will spend day 3 grading 40 model outputs against your real data or building a slide deck. The first 14 days make it legible. Named artifacts you can hold mean real work. Decks mean the next four weeks of build sit on nothing.
The 7 artifacts you should be able to count on day 14
A serious 14-day kickoff produces these seven files. By day 14, you should be able to attach each one to an email and walk a non-technical co-founder through it in twenty minutes.
| # | Artifact | What it is | Day landed |
|---|---|---|---|
| 1 | PRD draft | A 10-section product requirements doc with eval contract | Day 11 |
| 2 | Eval set v1 | 50-150 graded test cases against the central AI capability | Day 8 |
| 3 | Task taxonomy | A 5-15-row table of the AI’s named tasks with inputs, outputs, visibility | Day 7 |
| 4 | Cost model | A per-task line-item budget covering engineering, model, evals, integration | Day 13 |
| 5 | Capability probe | 40-input probe results on a current frontier model, founder-graded | Day 5 |
| 6 | Weekly cadence agreement | A signed one-pager: meetings, demo format, escalation path | Day 10 |
| 7 | Risk register | A named-risks list with owner, probability, mitigation, trigger | Day 12 |
Not on the list: a Jira project plan, a Slack channel, a kickoff deck, a “vision document,” or a brand-guidelines section. Those are setup, not work product. A partner who substitutes any of them for an artifact above is signaling that the artifact is not coming.
Artifact 1 — The PRD draft
A 10-section document, 12 to 25 pages: one-sentence idea, AI capability dependency, task taxonomy, eval set, failure-mode budget, no-AI fallback, integration surface, observability minimum, acceptance criteria, out-of-scope list. By day 11, every section is populated — not “TBD.” “AI capability dependency” and “failure-mode budget” cannot be hand-waved; they force the partner to commit on paper to which model, what failure rate, and what fallback. Vendors who cannot fill them by day 11 do not yet know if the product is feasible.
Hand-wave looks like: a “PRD outline.” Three populated sections, seven marked “to refine.” A Notion “Product Brief” that reads like positioning with no eval contract. If the document does not contain “eval,” “failure mode,” and “out of scope,” it is not a PRD.
Ask at day-14: “Show acceptance criteria for our top three model-dependent features.” If the partner invents answers, the PRD is theater.
Artifact 2 — The eval set v1
A spreadsheet, JSON file, or eval-tool project (Promptfoo, LangSmith, Braintrust, Inspect) with 50 to 150 test cases. Each case has input, expected behavior, rubric category (correctness, refusal, latency, format), and a pass-fail or 1-to-5 grade. Cases cover the founder’s actual data — not generic benchmarks. By day 8, v1 runs and produces a number per task that lands in the PRD on day 11. This is the artifact that distinguishes an AI MVP partner from a generic dev shop: generic agencies treat AI quality as post-build QA, while serious partners treat the eval set as the contract that defines “done” quantitatively, weeks before code is written.
Hand-wave looks like: a slide saying “we will use evals.” A generic framework deck without your data. A 10-case demo set. The most dangerous variant: “evals come in week 4 once the product is stable” — it sounds reasonable and guarantees the build ships against a vibe definition of done.
Ask at day-14: “Run the eval set live on a recent model. Show pass rates per task.” If the partner cannot run it in 15 minutes, it is a placeholder.
Artifact 3 — The task taxonomy
What you should see. A table with 5 to 15 rows. Each row is one named unit of work the AI is responsible for. Columns: task ID, name, input, output, user-visible, failure-mode budget reference. A sample for an email-triage product:
| ID | Task name | Input | Output | User-visible |
|---|---|---|---|---|
| T01 | Priority classification | Email body + context | Priority bucket 1-5 | Yes (label) |
| T02 | Rationale generation | Email + bucket | One-sentence rationale | Yes (hover) |
| T03 | Confidence calibration | Email + bucket + context | Confidence 0.0-1.0 | No (internal) |
| T04 | Escalation decision | Confidence + user policy | Escalate yes/no | Yes (modal) |
| T05 | Action logging | All of the above | Structured log entry | No (audit only) |
Signed by day 7, before the eval set is finalized — the taxonomy is the spine the eval set hangs off. Most product specs describe features the user clicks; a taxonomy describes work the model does. Many tasks are not user-visible. A partner producing a five-feature spec instead of a ten-task taxonomy is treating the AI as a black box — the failure mode that produces a demo that looks right and behaves wrong.
Hand-wave looks like: a user-stories document. A flowchart with boxes labeled “AI does the thing.” A single-task framing of a multi-task product. The build then ships with one eval, one prompt, and no observability on the bottleneck step.
Ask at day-14: “Walk me through the taxonomy and name the row most likely to fail in production.” If the partner cannot name the highest-risk row, the taxonomy is not thought through.
Artifact 4 — The cost model
A spreadsheet with line items, not a single budget number. Categories: engineering hours, model inference cost per request, eval-tooling, integration APIs, observability, hosting, contingency. Per-task estimates where applicable, plus a sensitivity row for traffic doubling, model-tier change, or eval-set growth. By day 13, this sits alongside the PRD and reconciles to the SOW fee plus founder-absorbed costs. A cost model is where vendor incentives leak. A partner showing only their fee and waving at “model costs are pass-through” has not done the unit economics; a partner producing sensitivity analysis is treating you as the operator you become at handoff.
Hand-wave looks like: a single number (“MVP build: $80K”). A budget omitting model inference or eval-tooling cost. “We will estimate ongoing costs after launch.” The post-launch surprise is the monthly model bill running half the founder’s burn.
Ask at day-14: “What is my per-active-user cost at 100, 1,000, and 10,000 users, holding eval pass rate constant?” If the partner cannot answer, the model is incomplete.
Artifact 5 — The capability probe
40 representative inputs run against a current frontier model — Claude Opus 4.8, GPT-5, or Gemini 2.5 Pro from the Artificial Analysis leaderboard — with outputs and founder grades. Binary or 1-to-5. The headline is one number: 31 of 40 useful or better. By day 5, the probe is run and graded. That number anchors every later decision.
The probe is the cheapest place to discover the central AI capability is below the product’s ceiling. A partner who refuses, or runs it after the PRD is signed, will not face the failure case. A partner who runs it early and shows you a 14 of 40 result has saved you the build cost on a product that would have failed. Willingness to surface a bad number on day 5 is the strongest tell the partner operates against your interests, not just their fee.
Hand-wave looks like: a “capability brainstorm” with sticky notes. A vendor demo against case-study data, not yours. A probe against a deprecated model. Fewer than 20 inputs. The partner grading their own outputs.
Ask at day-14: “Show the 40 inputs and grades. Did you grade or did I?” The founder must be the grader.
Artifact 6 — The weekly cadence agreement
A countersigned one-pager naming the weekly demo (day, time, length, format), the weekly eval review, the async Loom-demo cadence, Slack response-time expectations, decision-log location, and escalation path. It names what gets reviewed — not “we will discuss progress” but “per-task eval pass rates and the scope-decision log.” Signed by day 10. The agreement protects both sides from the predictable founder failure modes — the absentee founder who arrives at the demo with surprises, and the over-meddling founder who comments on every commit. Both are documented in the founder-AI-partner operating manual; the agreement is the mechanical fix.
Hand-wave looks like: a Slack channel and a recurring Friday meeting with no demo format and no escalation path. A calendar invite is not a contract.
Ask at day-14: “What artifact will we review at the eval review four weeks from now?” If the partner cannot name it, the cadence is decorative.
Artifact 7 — The risk register
A table of the top 5 to 10 named risks. Columns: risk, category (technical, scope, vendor, operational, regulatory), probability, impact, owner, mitigation, trigger. Sample row: “R03 — model API price increase mid-build. Vendor. Medium / medium. Owner: partner. Mitigation: prompt-pinning, secondary model fallback. Trigger: provider price change above 15% in weeks 3-6.” Signed by day 12, reviewed weekly. The register forces the partner to name what could go wrong on their watch. A 7-row register with AI-specific risks (model deprecation mid-build, eval-set data-quality failures, capability-probe regression on a model update) signals a partner who has shipped and remembers what happened.
Hand-wave looks like: “We mitigate technical risk through best-practice engineering.” A generic project-management list (schedule, scope, communication) with no AI-specific entries. No owner, no trigger.
Ask at day-14: “Which two risks have you actually been bitten by on prior engagements?” If the partner cannot answer, the register is generic.
What hand-wave looks like across all seven
Three signatures repeat:
- Activity in place of artifact. A workshop, a discovery call, a brainstorm, a slide deck — these are activities. An artifact is something you can attach to an email.
- Generic framework in place of your data. A “we will use evals” deck instead of an eval set against your data. Reusable artifacts are not yours.
- Deferral to “after we have more clarity.” A serious partner commits in writing on day 11 to 14, then refines. Deferred commitment becomes uncommitted, and the build ships against an unstated definition of done.
Pattern-matching these three at the day-14 review screens out a year of bad work in 30 minutes.
The day-14 review meeting: how to actually run it
Three rules.
Review artifacts, not slides. The partner will want a deck. Decline. Open each of the seven artifacts and ask the one question per artifact above. Hand-wave does not survive 90 minutes of direct artifact review.
Invite a second pair of technical eyes. A fractional CTO, an angel investor with engineering background, or a friend who has shipped an AI product. A $500 fee or a coffee. They catch eval-quality and taxonomy issues a non-engineer cannot. Y Combinator’s advice on evaluating technical work emphasizes external review at the kickoff gate.
Leave with a go / no-go in writing. Three documented outcomes: (a) go — sign the build SOW addendum, (b) go-with-revisions — name specific revisions in five business days, or (c) no-go — exit with a pro-rata refund and retention of artifacts. Option (c) should have been an explicit clause in the original SOW.
The companion piece, the anatomy of an AI agency engagement in the first 14 days, walks the seller’s-side rhythm.
Frequently Asked Questions
What if the partner produces only five of the seven artifacts by day 14?
Name the missing two and ask whether they land in three business days. Two missing is recoverable; four or more is not. If capability probe or eval set is missing, no-go regardless — those two are load-bearing.
Can the seven artifacts be produced in a one-week sprint instead of two?
For a narrow single-task product, sometimes. For a multi-task product, no. One week leaves no time for the founder to grade 40 probe outputs and write 50 to 150 eval cases — the eval set ends up shaped entirely by the partner, removing the founder’s audit lever.
What does this 14-day kickoff cost in 2026?
Fixed-fee, typically $20K to $40K for a single-product MVP. Under $15K buys a deck; over $50K pays for consultancy overhead the founder cannot defend.
What is the difference between this kickoff and a generic “discovery phase”?
Discovery produces a project plan and a budget. This kickoff produces seven artifacts including an eval set and a capability probe. The distinction is whether the central AI capability has been measured against your data before the build SOW is signed.
What is the founder’s time commitment across the 14 days?
Roughly 30 to 50 hours over two weeks. Grading probe outputs (3 hours), authoring eval cases (10 to 15 hours), the day-7 review (90 minutes), the day-14 audit (90 minutes plus prep).
What if the partner says the capability probe is unnecessary because the model is known to be capable?
Refuse. The probe is cheap; skipping it costs six to twelve weeks of build against an unverified assumption. Arguing against the probe signals inexperience or unwillingness to face a bad result.
Can the eval set be authored entirely by the partner?
No. The partner shapes rubric, threshold, and tooling; the cases must come from the founder’s domain knowledge. A partner-authored set is circular — the partner grades their own work against cases they invented.
How does this 14-day window interact with the 12-week operating rhythm?
This is weeks 1 and 2 of the 12-week founder-AI-partner operating manual. Weeks 3 to 6 are build; weeks 7 to 12 are hardening and post-launch.
What if my partner is one engineer, not a full studio?
The artifacts are the same. A solo senior produces them in 14 days; per-artifact rigor often tightens because no team dilutes decisions. The cadence is shorter — one async demo, one weekly call — but the list is unchanged.
Closing
The first 14 days are an audit, not an onboarding. Seven named artifacts: PRD draft, eval set v1, task taxonomy, cost model, capability probe, weekly cadence agreement, risk register. Count them, ask one question per artifact, leave with a go / no-go in writing. Other cluster guides — what an AI development partnership actually is and discovery call vs paid pilot — sit upstream of this window.
Subscribe to the SFAI Labs newsletter for weekly buyer-side guides to AI MVP engagements.
Arthur Wandzel
