Post-MVP for an AI product is not post-MVP for a 2018 SaaS product, and the founders who treat them as the same are the ones who watch launch quality erode in silence over six weeks. SaaS post-MVP is a growth-and-iteration period — measure adoption, ship features, raise the next round. AI post-MVP is structurally different. The product is probabilistic, the underlying model can change on a cycle of weeks, and the failure mode that hurts most — silent quality drift — is the one nobody notices until a customer complains, by which point the trust loss has already happened. This article maps what post-MVP actually requires when the product is built on a frontier model: the four required workstreams, the three founder failure modes that recur after launch, and what an MVP-2 scope typically contains in 2026.
It sits within the AI MVP economics playbook and the broader idea-to-product manifesto. Read it before scoping MVP-2.
Table of Contents
- Why Post-MVP for AI Is Not Post-MVP for SaaS
- The Four Things Post-MVP Requires
- The Three Founder Failure Modes After Launch
- What MVP-2 Typically Contains
- Frequently Asked Questions
- Closing
Why Post-MVP for AI Is Not Post-MVP for SaaS
A 2018 SaaS MVP shipped a deterministic product. The login worked or it did not. The integration tests that protected the launch could be re-run after every change, and a green build meant the product behaved the same way it did yesterday. Post-launch was a function of scale and growth — adoption, feature requests, the next round. The product sat still while the customer base grew around it.
A 2026 AI product shipped on a frontier model does not sit still. The model alias it is pinned to can be retired, updated, or silently re-routed on a cycle of weeks. Anthropic, OpenAI, and Google each shipped multiple frontier variants over the past year — each one a behavior change at the prompt surface. The launch eval set decays in two directions: the model behaves differently as the alias updates, and the input distribution drifts as users exercise patterns the launch set never sampled. The test set ages out of being representative.
McKinsey has reported across successive State of AI editions that roughly 80-85% of AI pilots fail to reach production at scale. That failure is primarily not a build failure — it is a failure to operate the MVP once it ships, to fund the post-launch lines an AI product requires and a SaaS product did not. In SaaS, the build was hard and the operation was easy. In AI, both are hard, and the operation has its own funded engagement profile.
The Four Things Post-MVP Requires
Post-MVP for an AI product is not a continuous-iteration retainer dressed up with a different label. It is a funded, scoped engagement with four required workstreams. A founder reading a vendor proposal should be able to point at each, name what bad looks like, and grade the proposal against it.
1. Eval Suite Expansion
The launch eval set is a snapshot with a graded rubric that proved the MVP cleared its quality bar on release day. Post-MVP, that snapshot has to grow. Real users use the product in ways the launch set did not sample; those new patterns need to flow back into the test set or the regression gate is silently grading against an obsolete bar.
The pattern that works: a weekly review of production traces, a triage step that pulls 20-50 new samples per week into the test set, and a re-run of the suite. After 8-12 weeks the eval set has grown from the launch baseline (100-300 cases) into a maturing test set (500-1500 cases). What bad looks like: the set stays frozen, the gate keeps passing, customers keep complaining, the team cannot explain the gap because CI is green. The eval test set every MVP needs before launch is the launch-side companion; expansion is the continuation.
2. Regression Suite Wired Into Releases
The regression suite is the eval set in its enforcement role. Every change — a prompt edit, a tool-definition update, a model alias change, a retrieval tweak — runs against the suite before it ships, and the suite fires a gate when the aggregate score drops below an absolute or delta threshold.
This is the only mechanism that catches silent quality drift before customers do. Without it, a frontier model update can shift behavior on a sub-population the team has not specifically tested, the weekly prompt update ships on top, and the combined effect is a 4-8 point drop on the cohort that matters most. The team will not see it. The customers will. What bad looks like: a release process that ships prompt changes the same day they are written, with no gate; a team that runs the suite manually once a month rather than on every release.
3. Production Observability
AI observability adds three things on top of the standard SaaS stack: trace-level visibility into the prompt, model output, and intermediate tool calls; per-trace cost telemetry because inference scales with usage; and a feedback channel that lets the team mark a trace good or bad and pipe labels back into the eval set. The AI agency observability stack we install on day one describes the operational pattern.
The concrete question for any post-MVP plan: can the team pull up any production trace from the last 30 days, see prompt, output, latency, cost, and mark it good or bad in one click? If no, the team is operating an AI product without the instruments the operation requires. What bad looks like: generic application observability (Datadog, New Relic, Sentry) without an LLM-native trace layer; cost reported monthly from a vendor invoice rather than per-trace; no feedback channel.
4. On-Call Rotation
An AI product needs an on-call rotation, but the profile differs from SaaS. The events that page the on-call engineer are not primarily outages — they are quality events: a customer reports a hallucination, a model alias update fires the regression suite, a cost-per-trace spike suggests an unbounded loop, a feedback signal trips a quality threshold.
The profile is closer to an enterprise integration than a vanilla SaaS app: lower volume of incidents, higher cognitive load per incident, more time in the trace explorer than in a stack trace. What bad looks like: no rotation, and the founder becomes the de facto on-call because customers email her directly. A 3am pager event becomes a churn event because the founder cannot diagnose a trace at 3am. The post-launch AI support primer covers the rotation shape in more depth.
The Three Founder Failure Modes After Launch
The four requirements above describe what good looks like. Three founder failure modes recur after launch across the cohort SFAI Labs has observed in 2025-2026 and across broader industry post-mortems.
Silent quality drift. The launch eval set passed. The product shipped. The team moved to building the next feature. Eight weeks later, a small cohort complains about output quality; the team runs the launch eval set and it is still green. The team cannot reconcile the gap because the eval set is grading an obsolete input distribution. By the time the team realizes the test set has aged out, the customers have churned. The cost is reputational, and the founder discovers it in a board meeting rather than a dashboard. The early signal is no growth in the eval set size after week two — if the test set has the same number of cases at week eight as at launch, drift is already happening; it is just not being measured.
Unmanaged on-call. Nobody is officially on call. Customers email the founder when something looks wrong. After three customer-side incidents, the founder calls the engineering lead at 11pm, and the response time on a paying customer’s complaint is 14 hours. The cost is churn — the kind of customer who tries an AI product, sees a hallucination, and never comes back. The early signal is the absence of a written rotation document. If there is no document, there is no rotation.
No eval expansion. The launch eval set sits frozen. New customer use cases, new failure modes — none flow back into the test set. The regression suite still runs; it still passes; it is grading against an obsolete bar. The cost is the quiet erosion of the quality moat the MVP was supposed to be built on. The early signal is a flat line on the eval-set-size chart.
These three failure modes compound. Silent quality drift is detectable only if the eval set is expanding and the regression suite is wired in. Unmanaged on-call extends the response time on every quality event the regression suite does fire. The composite outcome is the 80-85% post-MVP stall that recurs in the McKinsey numbers — not a build failure, an operations failure dressed up as an adoption failure.
What MVP-2 Typically Contains
A founder funding the post-launch period as a scoped engagement, rather than a vague retainer, should expect MVP-2 to look roughly like the shape below. The numbers are defensible 2026 ranges for a vendor-led MVP-2; an in-house build trades dollars for founder-and-engineer hours but the workstream shape is the same.
| Workstream | Typical scope | 2026 vendor range |
|---|---|---|
| Eval suite expansion | 8 weeks, weekly sample triage, target 500-1500 cases | $15K-$28K |
| Regression suite wiring | One-time wiring + per-release gate | $8K-$14K |
| Observability stack | LLM-native traces, cost telemetry, feedback channel | $10K-$22K |
| On-call rotation setup | Written rotation, runbooks, escalation path | $5K-$10K |
| First model migration | Eval re-run + prompt retune against next-frontier model | $8K-$16K |
| Founder reporting cadence | Weekly review, monthly board-ready metrics | $4K-$8K |
The total for a typical 8-week vendor-led MVP-2 lands $50K-$98K depending on which workstreams the in-house team absorbs — roughly 60-100% of the original MVP build cost. The mental model the founder arrived at the launch with — we will iterate from here — does not fit the cost shape of iterate when the product is probabilistic, the model is moving, and the test set has to grow.
Re-contract MVP-2 on a separate milestone agreement rather than extending the MVP contract — the work shape is operational and continuous, not capability-build, and bundling produces scope ambiguity. The idea risk stack is the companion piece on risks carried into post-launch; the AI MVP map covers the broader arc.
Frequently Asked Questions
Q: Is post-MVP for an AI product really different from post-MVP for a SaaS product?
Yes. SaaS post-MVP is mostly growth and feature work on a deterministic product. AI post-MVP adds eval suite expansion, a regression suite wired into releases, LLM-native observability, and an on-call rotation tuned for quality events rather than outages. None of those four lines existed as a separate workstream in the 2018 SaaS playbook.
Q: What is the single most common post-MVP failure mode for AI products?
Silent quality drift. The launch eval set stays frozen, the regression suite passes against an obsolete bar, customers complain about output, and the team cannot reconcile the gap because their CI is green. The fix is eval suite expansion — a weekly cadence of pulling representative samples into the test set so the regression gate stays calibrated.
Q: Do I need an on-call rotation with only a few hundred users?
Yes. Incident volume is low at that scale, but cognitive load per incident is high, and trust loss from a single unmanaged event is disproportionate. A lightweight written rotation with two-engineer coverage and a 4-hour business-hours response target is the minimum at any scale where customers pay.
Q: What does an AI-native observability stack look like?
Three things on top of standard application observability: trace-level visibility into prompts and model outputs (LangSmith, Langfuse, Honeycomb LLM, or vendor-native tooling), per-trace cost telemetry that ties inference spend to specific traces, and a feedback channel that feeds labels back into the eval set.
Q: How much should I budget for the first model migration?
Plan for one model migration inside the first 8-12 weeks. The work — re-running the eval suite against a new frontier model, tuning the prompt scaffolding for behavior shifts, and updating regression baselines — typically costs $8K-$16K in vendor terms or 1-2 weeks of senior engineer time in-house.
Q: Can I run MVP-2 on the same fixed-price contract as the MVP?
It is cleaner to re-contract on a separate milestone-based MVP-2 agreement. The MVP had deterministic acceptance criteria (the launch eval set cleared its threshold). MVP-2 criteria are continuous and operational. A separate milestone with four named deliverables and a single monthly report is the contract shape that works.
Q: How do I know when MVP-2 is done and steady-state operations have begun?
Three signals. The eval set has grown from the launch baseline to a maturing test set (500-1500 cases). The regression suite has fired and been resolved on at least one release. The on-call rotation has run for two cycles without escalating to the founder.
Q: What is the budgeting mistake founders make most often after the MVP ships?
Treating post-launch as a discretionary spend rather than a funded engagement. The founder budgets the MVP at $80K-$120K and assumes post-launch will be a low-touch $5K-$10K-per-month retainer. The actual shape lands at 60-100% of the original MVP cost over the first 8 weeks. The budget AI projects in eval runs, not story points piece argues the underlying frame.
Q: Should the same team that built the MVP run MVP-2?
Usually yes, with a re-contracted scope and a separate engagement. The build team has the context — eval rubric, prompt scaffolding, architecture decisions — and re-onboarding costs 2-3 weeks. The exception is when the build team is not staffed for production operations, in which case a handoff makes sense. The inside an AI agency post-mortem on shipping 12 production agents covers what the handoff looks like.
Closing
Post-MVP for an AI product is its own funded engagement — four workstreams, three recurring failure modes, and a 2026 cost shape at roughly 60-100% of the original MVP build over the first 8 weeks. The founders who treat it that way clear the post-launch period at quality. The founders who treat it as a SaaS-style iteration retainer arrive at week eight with a quality-eroded product and a customer base that has quietly moved on. The eval set is the spec, the eval set is the budget, and it has to keep growing after launch or the product stops being a product.
For the build phase, see the AI MVP economics playbook; for the broader frame, the idea-to-product manifesto. Subscribe to the newsletter for the next piece in this series.
Arthur Wandzel
