---
name: scoping-mvp-vs-production
description: Use when defining what ships first versus what is deferred, for a new AI feature or system.
---

# Scoping MVP vs Production System

## Overview

An **MVP proves value** on the happy path. A **production system survives** traffic spikes, provider outages, bad inputs, and your future self maintaining it. Conflating the two either never ships or ships debt that blocks the next feature.

## When to Use

- Kickoff for a new AI surface (assistant, copilot, classifier)
- Stakeholders want "full enterprise" on day one
- Skip when you are hardening something already validated in production

## Quick Reference

| MVP (prove it) | Production (survive it) |
|---|---|
| One core workflow | Full error taxonomy + retries |
| Single provider | Failover + graceful degradation |
| Manual spot-check evals | CI eval harness + regression suite |
| Basic logging | Traces, cost attribution, alerts |
| Feature flag / small audience | Rate limits, abuse protection |

## Implementation

1. **Name the one workflow** that proves the idea — cut the rest.
2. **Write a deferred list** with owners — not a silent backlog.
3. **Ship behind a flag** or to a narrow audience.
4. **Define the promotion gate** — what eval or metric unlocks production hardening.
5. **Schedule hardening sprint** after validation — before marketing scales traffic.
6. **Avoid permanent MVP** — if deferred items never get funded, say so explicitly.

## On This Portfolio

Gallery detail pages shipped as static content first; assistant routes stayed dynamic with observability hooks. Knowledge publish flows MVP'd on draft → published status before RAG indexing respected that gate in production.

## Common Mistakes

- Building multi-provider failover before anyone uses v1
- No written deferred list — MVP scope becomes permanent
- Skipping eval fixtures because "we'll add tests later"

## Related Skills

- Eval harness design
- Failure mode mapping before build
- Problem statement analysis