A 12-week AI MVP build does not fail on engineering; it fails on the seven in-flight calls a non-engineer founder must make between week 3 and month 4. Most of the literature on managing an AI build is either too strategic (build vs buy) or too tactical (how to run a standup). The middle layer — what specific decisions land in the founder’s lap, when, with what trigger, and at what cost if mishandled — is the part nobody writes down. This article is that decision tree.
It builds on the founder-AI-partner operating manual and the broader idea-to-product manifesto. Companion reading: the weekly founder-partner cadence — what good looks like, the founder briefing pattern, and inside the AI agency standup.
Why decisions, not features, decide AI MVP outcomes
A 2026 AI MVP build is a sequence of forks. Two engagements with identical SOWs, identical staffing, and identical scopes produce different products because the founder takes different forks at the named decision points. McKinsey’s The state of AI in 2025 reports 78% of organisations use AI in at least one business function, but BCG’s Where’s the value in AI? finds only about 25% of AI initiatives deliver expected value — and the variance correlates with decision quality on a small number of in-flight calls, not with engineering headcount.
A non-engineer founder who reads “decision quality drives outcomes” usually nods, returns to their inbox, and discovers in week 4 that a partner team has been waiting three days for a yes/no on a scope question. The fix is not more meetings. The fix is knowing in advance which calls will come, when, and what the founder’s role is for each.
The tree below lists seven. Each has a trigger that surfaces it, two or three options on the table, a defined founder-role (decide, approve, or be informed), and a named cost of getting it wrong. The tree is structural — every 12-week engagement hits these seven, in roughly this order, regardless of vertical.
The seven-decision tree at a glance
| # | When | Decision | Founder role | Cost of getting it wrong |
|---|---|---|---|---|
| 1 | W3 | Cut scope or hold scope | Decide | 2–3 weeks of timeline slip |
| 2 | W5 | Swap model or stay on baseline | Approve | 10–25% eval-score swing |
| 3 | W6 | Design the no-AI fallback | Decide | Bad-output incident in production |
| 4 | W8 | Launch on the date or extend | Decide | Soft launch with regressions |
| 5 | W10 | Extend on-call or end the SOW | Decide | 24/7 customer pain |
| 6 | W12 | Kick off the next feature or pause | Decide | Burn rate, dropped momentum |
| 7 | Month 4 | Re-engage, hire in-house, or switch | Decide | Wrong long-term cost structure |
The order matters. Decision 1 changes the inputs to Decision 4. Decision 2 changes the inputs to Decision 3. A founder who reads the tree in advance avoids the pattern of treating each call as a Thursday-afternoon surprise.
Decision 1 — Scope cut at W3
Trigger: by end of Week 3, the partner team has shipped the first thin slice and the eval suite v1 is running. The W3 Loom demo and eval scores together reveal whether the original scope fits the timeline. Almost always, one to three items in the scope are now visibly under-tested or under-resourced.
Options on the table:
- Cut the at-risk item(s), document them in a Phase 2 backlog, recover the time for items that survive.
- Hold the scope and re-budget — either add an engineer for two weeks or push the W8 launch to W10.
- Keep both scope and timeline, ship at lower quality across the board (the “soft fail” option — rarely the right call but founders pick it under deadline pressure).
Founder role: decide. The partner team can model the cost of each path, but the founder is the only person who can say which scope items are commercially load-bearing for the launch.
Cost of getting it wrong: cutting at W3 costs nothing — the team moves to other items. Cutting the same item at W6 costs three weeks of work thrown away. Cutting at W8 means a launch slip. The decision-cost curve is steep; W3 is the cheap window. Ask the partner project lead one question on Friday of W3 — “if you had to cut one item to protect the W8 launch, which would you cut?” If their answer matches yours, cut. If it does not, schedule a commercial-priority call before Monday.
Decision 2 — Model swap at W5
Trigger: by end of Week 5, the eval suite has run the full set against the chosen baseline (commonly Claude Sonnet 4.6, GPT-5, or Gemini 2.5 Pro depending on the partner’s stack) and the gap report identifies the three biggest quality gaps. One or more gaps point at the model layer rather than at prompting or retrieval. The partner asks whether to swap.
Options on the table:
- Stay on the baseline, close the gap with prompting, retrieval, or fine-tuning.
- Swap to a higher-capability model (Claude Opus 4.8, GPT-5 xhigh, Gemini 2.5 Pro Preview) and accept the per-call cost increase.
- Swap down to a cheaper or open-weights model (, Llama 3.3) and accept the quality risk to protect unit economics.
Founder role: approve. The partner owns the technical recommendation; the founder approves it because model choice changes three commercially-relevant things — cost per call (unit economics), IP exposure (data routing through a third-party API), and the eval-threshold timeline. Approval means asking three questions before signing off: what is the per-call cost change, what is the eval-score change in the gap report, and does the new model route data anywhere that violates an existing customer commitment.
Cost of getting it wrong: a swap done for the wrong reason — typically partner-team excitement about a new release — burns one to two weeks on integration and re-evals with no commercial benefit. A swap deferred when needed leaves the eval suite stuck below threshold at W6, forcing Decision 4 (launch readiness) into a “delay or ship broken” corner. Insist the partner produces a single comparison table — baseline vs proposed, with eval score by rubric dimension, cost per call, and IP routing for each. If they cannot produce it in 24 hours, the swap is not yet a founder decision.
Decision 3 — Fallback design at W6
Trigger: the production-readiness checklist for W6 requires the partner to define what the product does when the AI layer fails — model timeout, content-policy refusal, malformed output, latency overrun, or rate-limit response from the API provider. The partner surfaces the question once the eval suite reaches launch threshold and attention shifts to hardening.
Options on the table:
- Graceful degradation — the product returns a deterministic, narrower response that solves a subset of the user’s need without the AI layer.
- Human escalation — the request routes to a queue handled by the founder or a support agent within a named SLA.
- Refund or hold — the product refuses to act, refunds the user (if billed) or holds the request for retry, and notifies the user transparently.
Founder role: decide. This is a product-strategy call masquerading as a technical detail. The partner can implement any of the three; only the founder can say which one matches customer expectations and the product’s brand promise. A consumer product in a low-stakes domain can default to graceful degradation. A B2B product touching legal, medical, or financial data usually needs explicit human escalation.
Cost of getting it wrong: a missing fallback is the most common source of post-launch reputational damage. The most painful early-AI incidents are not model errors per se — they are model errors that reach the user because there was no fallback. Stack Overflow’s 2025 Developer Survey found “lack of evaluation rigor” is the top reason AI features quietly degrade; missing fallbacks are why that degradation reaches customers. Spend 30 minutes in the W6 review writing one paragraph per failure mode — what the user sees, what the system does, what the founder is notified about. If the paragraph cannot be written in plain English in 30 minutes, the fallback is not yet designed.
Decision 4 — Launch readiness at W8
Trigger: the partner team executes the launch-readiness checklist at end of Week 8 — observability dashboard live, model-version pinned, fallback paths implemented, auth/authz verified, logging schema in place, runbook drafted, on-call schedule named. The dashboard reads green, yellow, or red on each line. Ship on the planned date, or extend.
Options on the table:
- Ship on the planned date with all-green readiness — the design case.
- Ship on the planned date with one or two yellows, acceptable if non-blocking and the founder accepts the named risk.
- Extend the launch by one or two weeks to clear reds — almost always the right call when reds exist, even though it costs commercial momentum.
Founder role: decide. The partner owns the checklist execution; the founder owns the ship/extend call because a soft launch with regressions damages product reputation in a way that a two-week delay does not.
Cost of getting it wrong: shipping with a red almost always produces a P0 incident in the first 14 days. The companion piece what production-ready handoff looks like details the seven-artifact list. The cost of a two-week extension is bounded; the cost of a soft launch is unbounded because reputational recovery takes months. Ask the partner technical lead one question — “if you were the founder, would you ship Monday?” A hedged answer (“technically we could…”) is a no.
Decision 5 — On-call extension at W10
Trigger: two weeks after launch, the partner’s default on-call window is approaching its end. The partner has triaged incidents, the eval suite has been re-run against real production traffic, and the founder has data on what the product looks like with users.
Options on the table:
- Extend partner on-call for another 30–60 days at the agreed retainer, often reduced once acute issues are closed.
- End the SOW on schedule and transition to a “best-effort” support relationship with response-time commitments removed.
- Convert on-call to an embedded-engineer arrangement — one partner engineer remains for ongoing feature work alongside on-call coverage.
Founder role: decide. A product seeing weekly P1 incidents at W10 is not ready to drop on-call. A product seeing one minor incident in two weeks may not justify a 60-day extension.
Cost of getting it wrong: ending too early produces a 2am incident the founder cannot resolve and a customer who churns. Extending unnecessarily burns retainer dollars that would have funded the next feature. Incident pain is sharper than retainer pain by an order of magnitude. At the W10 review, ask the partner project lead to name the three most likely incidents in the next 30 days. If they can name them concretely with proposed runbook responses, on-call may be ready to ramp down. If they cannot, extend.
Decision 6 — Next-feature kickoff at W12
Trigger: at end of Week 12, the handoff is complete. The 90-day roadmap is written. The partner has documented what would change in the next quarter if the engagement continued. The founder has a quarterly roadmap and a finite budget.
Options on the table:
- Kick off the next feature immediately with the same partner team — best for momentum, worst for cost-discipline if the feature is not yet validated.
- Pause for two to four weeks to run customer conversations and refine the next-feature PRD — best for product-market fit, risks losing partner-team continuity.
- Switch to a smaller embedded-engineer arrangement for two months, then re-evaluate — best when the next feature is genuinely uncertain.
Founder role: decide. This is a portfolio decision — burn rate against learning rate. A founder who kicks off feature two without customer validation in between is paying twice. A founder who pauses too long loses partner-team continuity and pays a re-onboarding cost when the next engagement starts.
Cost of getting it wrong: GitHub Octoverse 2025 reports continued growth in AI-assisted development; the field moves fast enough that a six-month pause can mean re-architecting against new tooling. A two-month pause for validation is almost always cheaper than a four-month rebuild. Write a one-page decision memo before the W12 handoff meeting — three sections covering what we learned in the first 12 weeks, what the next bet costs, what would make us regret kicking off now. If the third section is blank, the call is “kick off.” If it has two items, “pause.”
Decision 7 — Partner re-engagement at month 4
Trigger: four months after the original SOW signed (typically one month after the post-launch period ends), the founder has data on traction and a view on whether the build paradigm — partner-led — is right for the next stage. The decision arrives whether the founder schedules it or not.
Options on the table:
- Re-engage the original partner for the next milestone.
- Hire an in-house engineering team — typically one or two engineers — and bring the codebase fully in-house.
- Switch partners for the next stage, either because the original is no longer the right fit or because a specialist (eval engineering, ML infra, compliance) is needed.
- DIY further with AI coding tools (Cursor, Claude Code, Lovable) — viable for some founders past a certain technical confidence, covered in the DIY-with-AI manifesto.
Founder role: decide. This is the highest-stakes call on the tree because it sets the long-term cost structure and the founder’s day-to-day operating mode for the next 6–12 months.
Cost of getting it wrong: hiring in-house too early commits the founder to recruiting and management overhead before the product warrants it. Re-engaging the same partner past their useful fit produces diminishing returns. The companion piece idea-to-product vs hiring a CTO goes deeper on the in-house path. Write down the question “what is the next $100K of engineering spend buying me?” If the answer is “more of the same product surface,” re-engage. If it is “a different shape of capability” (eval rigor, ML infra, compliance), switch or specialise. If it is “permanent capacity I can direct daily,” hire in-house. If it is “I am not sure yet,” pause 30 days.
The MoFu artifact: the AI MVP Scoping Worksheet
A decision tree is most useful when it points the reader at a worksheet they can fill in for their own build. The seven calls above presume a 12-week chronology and a clearly-scoped engagement; the AI MVP Scoping Worksheet is the artifact that produces that chronology in the first place — an eval-rubric template, scope-cut criteria, fallback-design prompt, and a launch-readiness checklist.
Download the worksheet, fill it in for your own product, and bring it to your next partner conversation. The decisions above will arrive whether you have prepared for them or not; the worksheet shortens the time between trigger and answer at every fork.
FAQ
What if my AI MVP build is six weeks, not twelve?
A six-week build collapses the seven decisions into roughly four named calls — scope cut at W2, model swap at W3, fallback at W4, launch readiness at W5. Decisions 5 and 6 typically get deferred because the on-call and next-feature windows are not yet open. Most six-week builds become twelve-week builds in practice via change-order; the seven-decision tree is the more honest shape.
Which decision do non-technical founders most often get wrong?
Decision 3 (fallback design) by a wide margin. It is the call that looks most technical — partner teams routinely under-surface it — but it is the call most directly visible to customers when it goes wrong. A non-technical founder who treats the fallback as a 30-minute product-strategy meeting in W6 avoids the most common post-launch incident.
Can I delegate any of these decisions to my AI partner?
Decisions 2 (model swap) and parts of Decision 4 (launch readiness) can be partner-led with founder approval. The other five cannot. Decisions 1, 3, 5, 6, and 7 require a commercial-priority or product-strategy call only the founder is positioned to make. Partners who push the founder to “let us handle it” on these five are usually either over-eager or testing founder authority — both worth pushing back on.
What if I miss a decision window — for example, I do not cut scope at W3?
The decision does not disappear; it gets more expensive. A scope cut deferred to W6 costs roughly three times what it would have at W3. A fallback design deferred past W6 typically gets shipped as a hasty post-launch patch. A model swap deferred past W5 forces an extension at W8. Missing a window does not unblock the next one, it compounds the cost.
Who is the founder supposed to talk to before each decision?
For Decisions 1, 4, 5, and 6, the conversation is with the partner project lead in the Friday standup. For Decision 2, the conversation is with the partner technical lead in a separate 30-minute call. For Decision 3, the conversation is with one or two target customers (testing the proposed fallback against actual user expectations). For Decision 7, the conversation is with two or three peer founders who have been through the same fork — not with the incumbent partner, who has an interest in path 1.
How do I tell if my partner is hiding a decision from me?
Three signs. Scope items quietly disappear from the weekly review without a recorded scope-cut decision — Decision 1 was made unilaterally. The model name in technical docs changes without a Decision 2 conversation — the swap happened without approval. The partner says “we will figure out the fallback during hardening” without a written W6 design — Decision 3 is being deferred. Each is worth surfacing at the next Friday standup.
Are these decisions different for B2C vs B2B AI products?
The triggers and timing are the same; the option weights shift. B2B products weight Decision 3 (fallback) toward human escalation because B2B customers expect a named owner for failure modes. B2C products weight Decision 5 (on-call) because consumer-incident recovery is faster but louder. B2B products weight Decision 7 toward in-house hiring sooner because long-term enterprise relationships favour in-house capacity.
Where does the AI MVP Scoping Worksheet fit in this decision tree?
The worksheet is the pre-W1 artifact that produces clean inputs to Decisions 1 through 4. A founder who arrives at W1 with a completed worksheet — eval rubric drafted, scope-cut criteria named, fallback strategy framed — encounters the seven decisions as planned forks rather than as surprises.
Closing
The seven calls above are the founder-shaped part of an AI MVP build. The engineering shape is real, but it is not what determines whether the product ships, lands with customers, or earns the next round of investment. The decisions do. A founder who keeps this tree on a wall above their desk — and comes back to it at W3, W5, W6, W8, W10, W12, and month 4 — runs a different engagement than one who treats each call as a surprise.
The next step is the AI MVP Scoping Worksheet. Download it, fill it in for your own build, and bring it to your next partner conversation.
Arthur Wandzel
