Why we stopped estimating AI MVPs by feature count, and what we use instead

Early on, we scoped MVPs the same way most teams do: list the features, estimate hours, and add a buffer.

It was wrong almost every time. Not because of scope creep or bad engineers, but because AI products have a fundamentally different risk profile from traditional software.

The features that look small on a spec sheet (hallucination mitigation, latency tuning, context window management) can eat a week each. The ones that look hard (the AI model itself) are often the easy part.

So we rebuilt our scoping model around time-boxed outcome gates instead:

Week 1: Data pipeline + baseline model integrated. Working end-to-end, even if it's rough.
Week 2: Evaluation framework live. We know what "good" looks like and can measure against it.
Week 3: Integration layer complete. The AI is talking to the real system, not a mock.
Week 4: Performance targets met. Latency within budget. Hallucination rate within an acceptable range. Ship-ready.

This forces hard conversations about scope in week 1 instead of week 4. It also means the client sees real progress every week, not a demo that falls apart in staging.

What does your MVP scoping process look like? Do you estimate by time or by output?