The 30-day post-launch period is the most under-explained line item in a 2026 AI MVP partnership. It is not “ongoing support.” It is not a retainer. It is not a free month of new features. It is a contractually bounded on-call window during which the team that shipped your product remains responsible for production incidents, eval regressions, and bug-level hotfixes — and stops being responsible for everything else. Founders who misread it burn the goodwill in week one. Founders who understand it walk out of week four owning the code, the evals, the runbook, and a clear renewal-or-graduate answer.
It builds on the founder-AI-partner operating manual, the practical guide for non-engineer founders running an AI partnership, and sits within the idea-to-product manifesto, the master guide for non-engineers shipping AI products in 2026.
The plain-English working definition
The 30-day post-launch period is a contractually bounded on-call window — calendar days, not engineering days — that begins the day your AI MVP enters production and ends 30 calendar days later. During the window the partner team remains responsible for four categories of work: production incidents, eval regressions, hotfixes for escaped bugs, and the close-out review that transfers full operational ownership to the founder.
Five clauses carry the weight.
| Clause | What it means |
|---|---|
| “30 calendar days” | Clock starts at production cutover, not contract close. Holidays count. Delaying launch does not extend the window. |
| “On-call, not embedded” | Reachable on a defined SLA — Slack-first, 4-hour business-hours, 24-hour off-hours — but no standing hours. Tickets pull time; idleness does not. |
| “Production incidents, eval regressions, hotfixes” | Three failure categories, all reactive. New features, integrations, and model migrations are out of scope. |
| “By the team that built it” | Same engineers, same eval engineer. The point is institutional memory. |
| “Close-out review on day 30” | A 60-minute meeting that hands off remaining artifacts and triggers the renewal-or-graduate decision. |
The window is the operational bridge between handoff and standalone ownership — designed to absorb failures that only appear under real production traffic, then end. McKinsey’s State of AI puts pilot-to-production stall rates at 80–85%; the 30-day window is the engagement shape designed to land on the production side of that line and exit cleanly.
What the window covers — four real incident categories
A founder who has never run an LLM product in production reads the SOW and pictures “bugs.” The picture is incomplete. The four categories below are what actually fills the ticket queue in 2026.
Category 1 — P0/P1 production incidents. P0: the product is unusable for all users (API 5xx, model timeouts, queue worker wedged, auth broken). P1: degraded for a meaningful slice (inputs silently failing, an integration rate-limited, an embeddings index stale). The founder’s job during a P0 is not to debug — it is to provide three evidence pieces within fifteen minutes: timestamp of first failure, screenshot of user-facing symptom, and (if known) eval-dimension scores from before and after.
Category 2 — Eval regressions. The failure mode almost no founder anticipates. A previously-passing eval dimension starts failing at a measurable rate. Three causes: a model provider silently changes behavior on an unpinned alias; a prompt was edited in a hotfix with unintended consequences; real-world inputs drift away from the eval seed set. The partner’s eval engineer owns diagnosis. The founder authorizes new eval seeds when traffic diverges, and decides whether a given dimension matters enough to hold a fix for. The eval-first build playbook covers the rubric mechanics upstream.
Category 3 — Hotfixes for escaped bugs. A code change for a specific bug that survived pre-launch testing. Classic case: a user pastes a malformed PDF, the OCR pipeline returns empty text, the prompt that consumes it fails silently. The eval set didn’t include malformed PDFs. Production did. Hotfixes are bounded — one bug, one root cause, one eval addition to prevent recurrence. Bundling three feature requests inside a hotfix ticket is the most common scope-creep mistake in the window.
Category 4 — Token-cost spike investigations. LLM costs scale with usage in ways conventional cloud costs do not. A founder who launches at $200/day in inference and wakes up to $2,000/day is in a token-spike incident. Common causes: a runaway retry loop, a misbehaving user, a prompt that grew context-window-sized after a hotfix, or genuine product-market fit demanding architectural change. The hidden cost of AI token bills editorial covers the observability dimension.
What the window does not cover — five scope-creep traps
The opposite half of the definition matters as much. The five traps below burn more 30-day windows than any genuine bug.
| Trap | What founders ask for | Why it is out of scope |
|---|---|---|
| New features | “Can we add a CSV export?” | New scope. The on-call window absorbs production failures, not product expansion. |
| New integrations | “We just signed a deal that requires a Salesforce sync.” | A new project, with its own architecture, eval set, and time budget. |
| A second model migration | “Can we swap from the current model to the new release?” | Migration triggers a full eval-suite re-baseline and is a multi-week engagement. |
| Perf tuning beyond the rubric | “Can we get latency down another 200ms?” | If the rubric lacks a latency dimension, this is new work. If it has one, it is a regression (Category 2). |
| Roadmap discovery | “Can we use the support hours to plan v2?” | Discovery, roadmap, and prioritization belong in a fresh engagement or a fractional CTO retainer. |
The 10 rules of working with an AI agency editorial is worth re-reading here. A founder who frames every new request as a “small bug fix” trains the partner to treat the relationship as adversarial.
The cost shape — included vs add-on, in dollars
Three commercial shapes the 30-day window takes in a 2026 idea-to-product partnership.
Shape 1 — Included in the partnership SOW (most common). A $150K–$200K idea-to-product partnership (described in what is an AI development partnership, in plain English) includes the window in the closing milestone, with a 20-to-40-hour cap drawn against actual incidents. Unused hours expire. The cap is why the incentive structure works: the partner wants a production-stable handoff because ten incidents eat the whole budget.
Shape 2 — Add-on bolted on ($5K–$15K). Some partnerships price the window separately, especially when a founder signed a build-only SOW and decides post-cutover they want institutional memory available. Pricing varies with engagement size, SLA, and cap. A bolted-on window often signals the original SOW was scoped badly.
Shape 3 — Retainer ($3K–$10K/month) after the window. If the founder reaches day 30 not yet ready to stand alone, the partner often offers a 3-to-6-month retainer — 1 day per week of reserved engineering, minor feature work allowed, SLA dropped to next-business-day. The bridge between partnership and standalone ownership, not an extension of on-call. Compare against the in-house alternative: a senior AI engineer in 2026 costs $200K–$280K fully loaded; a fractional CTO at one day a week costs $4K–$8K/month.
Founder behavior the window is structured around
The window is designed for a particular founder behavior. Founders who default into it find 30 days is enough; founders who default away from it find 30 days disappears in confusion.
File incident tickets, not Slack pings. A ticket has a timestamp, symptom description, evidence, and severity (P0/P1/P2). A Slack ping has none of that. The partner’s incident-response process is built around tickets.
Run the first solo eval review. Around day 7 to day 10, run the eval review without the partner in the room. The point is to discover whether you can run it alone before the partner exits.
Distinguish bug vs scope-change, in writing. Label every request in the ticket: “bug” (under the window), “scope change” (needs a new SOW), or “clarification” (15-minute call). Founders who label everything as a bug force the partner into refusing things — and the relationship cools fast.
Schedule the close-out review on day 1, not day 30. The day-30 close-out triggers the renewal-or-graduate decision, the IP transfer document, the handoff checklist, and the partner’s exit. Book it on day 1.
The four behaviors that burn post-launch goodwill
Treating Slack as 24/7. Pinging the channel at 11pm on Sunday for a non-emergency teaches the partner the SLA is meaningless. Off-hours means off-hours.
Feature requests dressed as bug fixes. Writing “the CSV export button doesn’t work” when the CSV export button does not exist yet. The partner triages, discovers the misclassification, and now must either politely decline (souring the relationship) or absorb out-of-scope work (burning the cap). Honest labels avoid both.
Ghosting the eval baseline. The partner’s eval engineer spends the first week establishing a production-baseline eval — scores under real traffic vs pre-launch synthetic. A founder who ignores the baseline review loses the most useful artifact of the 30 days: a defensible “here is what good looks like, in numbers” reference point.
Missing the close-out review. The partner prepares a runbook delta, eval-score export, IP-and-weights summary, on-call handoff document, and written recommendation. A founder who reschedules twice signals the artifacts are not valued; the partner team’s incentive on the next engagement drops. The sunk-cost trap and 30-day kill rule editorial covers the upside of treating day 30 as a real decision point.
Two endpoints — close-out review vs silent expiration
A 30-day window ends in one of two ways. Founders should know which they are headed for by day 20.
Endpoint A — Close-out review (the intended ending). A 60-minute meeting on day 30. The partner walks through the runbook delta, the final eval-score state (vs the launch baseline), and a written recommendation: graduate to standalone, sign a retainer, or hire in-house. The founder signs the IP-and-weights transfer and either signs a retainer SOW or schedules final repo access removal.
Endpoint B — Silent expiration (the avoidable failure). Day 30 passes. No close-out was scheduled. Three weeks later the founder asks a question and gets a polite reply suggesting a new SOW. The biggest predictor of silent expiration is missing the close-out’s calendar slot — preventable by booking it on day 1. The anatomy of a runaway AI project covers what happens to engagements that do not close cleanly; the close-out review is the structural antidote.
Frequently asked questions
Is the 30-day post-launch window the same as a maintenance retainer?
No. A retainer is ongoing with reserved hours (typically 1 day/week), monthly billing ($3K–$10K), and a next-business-day SLA. The 30-day window is a one-time, calendar-bounded on-call period with a small cap drawn against actual incidents only, no monthly billing, and a 4-hour business-hours SLA. It is the bridge that lets a founder decide whether to buy a retainer.
Is the window included in the partnership cost, or billed separately?
In most 2026 idea-to-product partnerships ($150K–$200K), the window is included in the closing milestone with a 20-to-40-hour engineering cap. If billed separately, it runs $5K–$15K. Ask explicitly during partner selection: “Is the 30-day on-call window in the SOW, and what is the hours cap?”
What is the response SLA during the window?
Typical 2026 SLAs: P0 — 1-hour acknowledge, 4-hour business-hours response, 24-hour off-hours. P1 — 4-hour acknowledge, 1-business-day response. P2 — 2-business-day. Smaller partnerships often have business-hours-only SLAs with explicit off-hours best-effort language.
Can I extend the window if a major incident eats the hours cap?
Sometimes — at the partner’s discretion, usually with a small overrun fee. A clean partnership has a clause: hours over the cap bill at a defined hourly rate, capped at one week’s worth. A partner-side quality miss should be absorbed by the partner; disguised scope is billable.
Does the partner own anything after day 30?
No. Code, evals, runbook, model-version pins, and the production observability dashboard have belonged to the founder since the original handoff. The window is access-and-on-call, not ownership. The close-out review removes repo access, archives the Slack channel, and finalizes the IP-and-weights transfer.
What if I want the partner to keep working past day 30 on new features?
A new SOW with new scope and new pricing. Schedule a scoping call inside the window, produce a fresh SOW by day 25, sign by day 28 so there is no operational gap.
How does the 30-day window interact with model deprecations?
A model deprecation announced inside the window (a provider announces a 90-day deprecation for the model your build pins to) is a forced migration with its own scope, not a hotfix. The partner flags it, documents the migration path, and offers a separate engagement.
What happens if I miss the close-out review?
The partner team de-prioritizes the engagement. Repo access remains technically open but the team is re-allocated and SLA reverts to “best effort, paid hourly.” The remedy is a paid retro session — $1K–$3K — to recover the artifacts. Recoverable, but avoidable.
Can a non-engineer founder run the window alone?
Yes, if the founder commits 3–5 hours per week, files structured incident tickets, runs the first solo eval review, and labels every request as bug-vs-scope-change. The founder’s role in an AI MVP build is the upstream reference.
Key takeaways
| Takeaway | Implication for the founder |
|---|---|
| The window is on-call, not embedded | Tickets pull time; idleness does not. Don’t expect proactive feature work. |
| Four real incident categories (P0/P1, eval regression, hotfix, token spike) | Build literacy to file each kind of ticket clearly. |
| Five scope-creep traps | Label requests honestly; new scope needs a new SOW. |
| Usually included in $150K–$200K SOW; $5K–$15K as add-on; $3K–$10K/month retainer after | Ask explicitly during partner selection. |
| The close-out review on day 30 is the most important meeting | Book it on day 1, not day 25. |
| Founder behavior matters more than the contract | The same 30 days can produce a clean exit or silent expiration. The variable is the founder. |
A 30-day post-launch window is short, bounded, and unforgiving of disorganization. Treated like a budget for new features, it disappears in noise. Treated like the operational bridge it is — incident-first, eval-grounded, founder-owned — it produces the artifacts and the close-out decision that turn a shipped MVP into a standing AI business.
Arthur Wandzel
