A non-technical founder should show up in person for five things during an AI build — the weekly eval review, any scope-cut decision, at least one customer call per sprint, the go/no-go demo, and the handoff signoff — and fully delegate five others: model selection, infrastructure picks, code review, observability configuration, and the on-call rotation. Total founder time: roughly three to five hours a week. Most founders get the role-split right on paper and then get the attention-split wrong — sitting in on standups they cannot evaluate and skipping the eval review they could. This article is the calendar version of the founder’s role.
It builds on the founder-AI-partner operating manual, part of the broader idea-to-product manifesto. Companion reading: the founder’s role in an AI MVP build, how an engagement actually works week-by-week, the role of evals in your weekly partner relationship, and the anatomy of a great AI agency kickoff.
Why show-up vs delegate is the right axis
Most founder-role frameworks stop at the ownership column — the founder owns the spec, the partner owns the engineering. That is correct but it is not the question a founder asks at 8am on Monday. The real question is: which calendar entries require me, and which can run without me?
Bain’s CEO Agenda 2026 argues that the highest-impact executive input is concentration of synchronous attention on a small number of decisions, not breadth of involvement. Saying “I own the product spec” is identity; saying “my body needs to be in this 60-minute meeting on Thursday or the build drifts” is a calendar commitment. Only the second one ships products.
McKinsey’s The state of AI in 2025 reports that 78% of organisations now use AI in at least one business function and that direct executive time on AI redesign work is the top correlation with revenue impact. The founders whose builds ship on time do less, more deliberately.
The five meetings the founder must show up for
These are the five where the founder being in the room is the difference between a calibrated build and a drifting one.
1. The weekly eval review — 60 minutes, every week
The eval set is the only place where ground truth gets calibrated — where the partner’s interpretation of “correct” is checked against the founder’s. The partner walks through the week’s eval delta (passed, failed, moved); the founder confirms or rejects labels on a sampled subset; they decide whether to iterate or escalate a prompt change. A founder who skips this meeting is letting someone else define what good looks like. For the deeper case, see the role of evals in your weekly partner relationship.
2. The scope-cut decision — 30 to 60 minutes, whenever the partner flags one
Every AI build of meaningful complexity hits a moment in week 5, 6, or 7 where the original scope cannot fit the remaining calendar. The partner brings the trade-off; the founder makes the call. This cannot be done over Slack — the trade-off is rarely binary, and the founder usually needs three or four follow-up questions before committing. Scope cuts handled asynchronously almost always defer the hardest conversation, which is usually the wrong call.
3. The customer call — at least one per sprint, 45 to 60 minutes
The partner cannot fake the customer voice. Call notes, recordings, and themes do not substitute for the founder hearing the seven seconds of hesitation when the customer is asked whether they would actually pay for this. The partner runs customer sessions independently during weeks 2 through 8; the founder must be on at least one call per two-week sprint.
4. The go/no-go demo — 60 minutes, in week 9 or 10
The signoff before launch. The partner demos the full system end-to-end against the eval set and the launch checklist; the founder signs off or sends it back. Go/no-go is a judgment, not a checklist — the eval set passes or fails on numbers, but launch turns on whether those numbers, in context, are what the founder is prepared to put their company’s name behind. See what you should expect from your AI MVP partner in the first 14 days for the kickoff-side companion.
5. The handoff signoff — 90 minutes, in week 12
The moment IP transfers. The partner walks through the codebase, README, deployment runbook, cost dashboard, and eval set; the founder takes formal ownership and confirms the artifact list against the SOW. The founder need not understand every line of code, but must be in the room when the partner explains the operating boundaries — what is documented, what is not, what assumptions live where, what the on-call escalation path is. That context is delivered verbally or it is lost.
The five things the founder should fully delegate
These are decisions where a non-engineer founder should not be a vote, an approver, or a reviewer. The partner owns them; the founder’s job is to refuse to weigh in even when invited.
1. Model selection
Which model the system runs on — Claude Opus 4.8 vs Sonnet 4.6 vs GPT-5 vs Gemini 2.5 vs Llama 3.3 — is a partner decision. The factors are latency, eval performance, cost per call, context window, tool-use reliability, and vendor reliability — none in the non-technical founder’s wheelhouse. The partner reports which model was chosen and why, and switches if eval performance changes. A founder who insists on a specific model has confused brand familiarity with technical fit.
2. Infrastructure picks
Hosting, vector database, queue, background-job runner — all of it. The partner owns the stack; the founder owns the budget envelope and the production-readiness criteria, not the components. The right founder question is “are we within the infra budget I signed?” — not “why did we pick pgvector?”
3. Code review
A non-engineer founder reading pull requests is theater that consumes hours and produces no signal. The partner has reviewers, linters, CI, and engineering managers internally. The founder’s job is to review behavior, not code. GitHub’s Octoverse 2025 confirms the pattern: founders increasingly review what systems do, not how they are coded. The right review surface is the eval set and the demo.
4. Observability configuration
How the system is instrumented — Langfuse, OpenTelemetry, DataDog, Sentry, alert routes — is a partner decision. The founder needs one dashboard, not a vote on provider choice or alert thresholds. What the founder should require is a single weekly observability summary: latency, error rate, cost burn, and any anomaly worth a sentence.
5. On-call rotation
After launch, somebody pages when the system breaks at 3am. That somebody is not the founder. The partner owns the post-launch on-call rotation through at least the 30-day stabilisation window — rotation membership, escalation, response-time SLA all governed by the SOW. See the 30-day post-launch period explained.
The weekly hour budget
Total weekly founder time on a 6-to-12-week AI build should land between three and five hours. Above that, the founder is doing the partner’s job; below it, the build drifts.
| Activity | Cadence | Founder time per week |
|---|---|---|
| Weekly eval review | Every week | 60 minutes |
| Customer call sit-in | Every other week (avg) | 30 minutes |
| Scope/PRD decisions (sync) | As needed | 30 to 60 minutes |
| Async PRD review / Slack | Throughout | 30 to 45 minutes |
| Demo and signoff prep | Weeks 9 to 12 | 30 to 60 minutes |
| Total | 3 to 5 hours |
The eval review is the only non-negotiable hour. The budget concentrates in weeks 1 to 2 (kickoff, PRD) and weeks 9 to 12 (signoff, handoff). It does not include parallel founder work — go-to-market, fundraising, customer development — which usually consumes 4× to 10× the engagement-bound hours.
The diagnostic question: am I spending these hours, in these meetings, on these decisions? If the hours are going somewhere else, the engagement is in trouble even if no one has said so.
Three anti-patterns where founders over-show-up
Each of these substitutes founder presence for partner judgment in a place where presence adds no value.
1. Reviewing pull requests
A non-technical founder reading a diff is performing concern, not exercising judgment. The diff is not the right review surface; the eval set is. The fix for the underlying anxiety is to invest harder in eval review, not to add a second surface the founder cannot evaluate.
2. Picking the model or the framework
Founders who arrive at kickoff with a strong opinion on model or framework choice (LangChain vs LlamaIndex vs DSPy vs hand-rolled) have usually read one good blog post and overweighted it. The partner has seen ten builds across the same surface. Overriding here costs hours and the partner’s confidence that the SOW is held to scope.
3. Sitting in on every engineering standup
The engineering standup is a partner-internal meeting. Founder attendance turns it into a status meeting — the partner stops surfacing actual blockers and starts narrating progress. See inside the AI agency standup — the standup works when the founder is not in it.
Three anti-patterns where founders under-show-up
These are costlier than the over-show-up failures because they fail silently. The founder thinks the engagement is going well right up until week 9 when it isn’t.
1. Skipping the eval review
The most expensive missed meeting. When the founder is absent, the partner calibrates ground truth alone: edge cases the founder would flag get labeled passing, and the partner ships a system that scores well on the eval set but underperforms in the customer’s hand. There is no acceptable substitute, including watching the recording later.
2. Cancelling customer calls
When founders are busy, the customer call is the first meeting they cancel — because the partner is running it anyway. But the partner running calls without the founder produces clean call notes and unclean product judgment. Minimum: one founder-attended call per two-week sprint.
3. Skipping the go/no-go demo
A founder who delegates the launch decision, or signs off based on a Slack summary, has given up the only veto that matters. Launch is a judgment that turns on context the founder owns. Book the W9/W10 demo at kickoff and do not let it move.
How to know the split is working
Four signals from week 3 onward. First, the eval-review meeting has concrete disagreement most weeks — actual debate about whether Row 47 should pass. A meeting that is always a clean “everything passed” means either the eval set is too easy or the founder is not really reviewing.
Second, the partner makes infra and model decisions without asking. They report; they do not seek permission. A partner escalating every model swap has not claimed the delegate column.
Third, the founder’s weekly time is stable at three to five hours. A creeping calendar — six, then seven, then nine — is a leading indicator that the founder is over-engaging.
Fourth, scope cuts happen with the founder in the room, not in Slack. For the broader rules that protect founder authority through an engagement, see the 10 rules of working with an AI agency.
Want the rest of this operating manual delivered week by week? Subscribe to the SFAI Labs newsletter and we will send the full operating-manual sequence — the operating manual, the first 14 days, the eval-review playbook, and the handoff signoff template.
FAQ
How many hours per week should a non-technical founder spend on an AI build?
Three to five hours per week is the right budget for a 6-to-12-week build. That concentrates in the weekly eval review (60 minutes) and customer or scope-cut decisions (60 to 120 minutes), plus 30 to 60 minutes of async PRD and Slack review. Above five hours, the founder is doing the partner’s job; below three, the build drifts.
What meetings must I attend, and which can I skip?
Five are non-negotiable: the weekly eval review, any scope-cut decision, at least one customer call per two-week sprint, the go/no-go demo in week 9 or 10, and the handoff signoff in week 12. Engineering standups, model-selection meetings, infra-architecture reviews, code reviews, and observability configuration are all delegate-able. Founders attend behavior and judgment meetings; they delegate technique and tooling.
Why shouldn’t I pick the model or infrastructure?
Model and infra choices turn on latency, eval performance, cost per call, context window, and vendor reliability — none of which a non-technical founder can evaluate without weeks of work. A partner who has shipped ten builds has internalized the trade-offs. The right founder oversight is the budget envelope and the eval bar, not the component.
What if the partner asks my opinion on a technical choice I should be delegating?
Decline politely and ask them to make the call. Partners sometimes offer participation out of inclusion. “You pick. Tell me what you chose and why in the weekly summary” is the right response.
How do I attend the eval review without understanding the technical metrics?
The eval review is not a metrics meeting. The founder looks at the system’s outputs on representative inputs and confirms whether each output is acceptable for the customer. The partner handles precision and recall; the founder handles the qualitative label on a sampled subset. If the partner cannot run an eval review a non-technical founder can fully participate in, that is a partner-side problem.
What’s the most expensive meeting to miss?
The weekly eval review. Missing it lets the partner calibrate ground truth alone — producing a system that passes the eval set and fails the customer test. The second most expensive miss is the go/no-go demo; the third is the customer call.
How do I fit the weekly hour budget alongside the rest of my company?
Block the five must-attend meetings at the start of the engagement, before the rest of the calendar fills. Eval review on a fixed weekly slot. Customer call on a fixed sprint slot. Demo and handoff on the calendar before week 1 ends. Founders who fit the engagement into the gaps of an already-full calendar are the ones who under-show-up.
What does “fully delegate” mean in practice?
The partner makes the decision, reports it in the weekly summary, and does not require founder approval to act. The founder asks clarifying questions only on eval-bar or budget-envelope dimensions. Fully delegated does not mean “uninformed”; it means “non-blocking”.
How do I know if my partner is letting me over-engage?
Two tells. The partner forwards every minor decision for founder approval (model choice, framework, infra component), and the partner invites the founder to engineering standups or PR reviews. The fix is a kickoff conversation that re-affirms the delegate column out loud.
How does this relate to the broader founder-role guide?
The founder’s role guide covers the ownership axis — which columns belong to the founder vs the partner. This article covers the attention axis — which of those owned columns require synchronous founder presence. Read the role guide first, then this one.
Arthur Wandzel
