MVP Design

Phase 15 · Document 04 · Startup Playbook Prev: 03 — AI-Native Product Design · Up: Phase 15 Index

Table of Contents

1. Why This Matters
2. Core Concept
3. Mental Model
4. Hitchhiker's Guide
5. Warmup Readings
6. Deep Readings and External References
7. Key Terms
8. Important Facts
9. Observations from Real Systems
10. Common Misconceptions
11. Engineering Decision Framework
12. Hands-On Lab
13. Verification Questions
14. Takeaways
15. Artifact Checklist

1. Why This Matters

This is the doc where strategy becomes a buildable plan. You have the pain (01), the market (02), and the AI-native design principles (03); the MVP is the smallest thing you can ship to real users to learn whether they'll adopt and pay. The classic trap — fatal and common — is spending three months on infrastructure before talking to users: building a gateway, a fine-tuning pipeline, and a slick UI for a product nobody wants. The opposite discipline is what wins: ship an embarrassingly simple first version fast, get it in front of real users, and let their behavior drive what you build next. This doc gives you the concrete MVP spec the whole curriculum feeds into — ICP, workflow, model/RAG/agent choices, eval and cost plans, security posture, a demo that converts, and a 30/90-day plan — so you build the right minimal thing, not the most thing.

2. Core Concept

Plain-English primer: the smallest thing that delivers real value to real users

An MVP (Minimum Viable Product) is not a worse version of your eventual product — it's the smallest complete thing that delivers genuine value for the core workflow and lets you learn. "Viable" matters: it must actually do the job well enough that a real user gets value (and ideally pays), not a half-thing that frustrates. "Minimum" matters equally: everything not essential to the core workflow is cut. For LLM products, the MVP can often start shockingly simple — a hardcoded prompt and a CLI — because the model does the heavy lifting; the risk is over-building infrastructure before validating demand.

NOT an MVP: 3 months of infra (gateway, fine-tune pipeline, polished UI) before any user touches it → built the wrong thing
MVP: the smallest COMPLETE slice of the ONE core workflow [03] that delivers real value → ship in weeks → learn from real users → iterate

The minimal infra principle: start embarrassingly simple

The instinct to build infrastructure first is the enemy. The right sequence (from 00's lab and The Lean Startup):

• Week 1: hardcode a prompt, ship a CLI/Streamlit, get ~5 real users.
• Weeks 2–4: iterate the prompt/workflow on their feedback; add minimal persistence.
• Weeks 4–8: build the eval set once you know what "good" means (Phase 12); instrument cost (05).
• Later: the gateway, routing, fine-tuning, polished UI — only once demand and the workflow are validated.

You can wrap a model for the MVP (to validate) even though a wrapper isn't a durable product (03) — the MVP's job is to learn, then you build the moat. Don't confuse the throwaway validation MVP with the defensible product.

The MVP spec (the twelve concrete pieces)

For your chosen idea, define each (this is the deliverable):

1. ICP — exactly who the MVP is for (from 02).
2. User stories — "As a [role], I want to [job], so that [outcome]" for the core workflow (01 JTBD).
3. Critical workflow — the one end-to-end path you'll nail (03); everything else is cut.
4. Model choice — which model(s), and why (capability vs cost vs latency, Phase 5); start with a capable API model, optimize later.
5. RAG design — if the workflow needs your/customer data: ingestion, chunking, retrieval (Phase 9); keep it minimal.
6. Agent/tool design — only if the workflow needs actions/tools; "least-agentic that works" (Phase 10/Phase 10.05).
7. Evaluation plan — the golden set + metric for the core workflow (Phase 12.01); built early, not at launch.
8. Cost model — estimated cost per task and the target margin (05).
9. Security posture — the minimum from Phase 14: no secrets in prompts, PII handling, tenant isolation if multi-user, the trust boundary on any action.
10. Demo script — the 3–5 minute story that makes the value undeniable (see below).
11. 30-day build plan — what ships in the first month (the embarrassingly-simple version).
12. 90-day launch plan — first paying users, the eval/cost instrumentation, the first moat investments.

Scope discipline: cut to the core workflow

The hardest MVP skill is saying no. Every feature not on the critical path of the one core workflow is deferred. Auth, settings, dashboards, multi-workflow support, integrations beyond the essential one — later. If a feature doesn't help validate "will they adopt and pay for this workflow?", it's out of the MVP. Concretely: one workflow, one ICP, one model (to start), the minimal RAG/agent the workflow needs, and the trust/security/eval/cost minimums.

The demo script (your most important sales/learning artifact)

For an LLM product, the demo is the product in early stages — it's how you validate (01), sell (07), and fundraise (09). A converting demo:

• Opens on the customer's painful "before" (the 3-hour manual task).
• Shows the "after" on real (or realistic) data — the job done in minutes.
• Highlights the trust features (citations, the human-approval step) so it's believable, not magic (03).
• Ends on the outcome (time/cost saved) and a call to action (pilot/payment). Practice it; it's the artifact you'll use most.

The 30/90-day plan: ship, then prove

• 30 days: the embarrassingly-simple version doing the core workflow for a handful of design-partner users; collect feedback and the first eval examples.
• 90 days: first paying customers (or signed pilots), a working eval harness and cost instrumentation (Phase 12/05), and the first moat investments (system-of-record/action ownership, 06). The plan turns the MVP from a validation toy into the seed of a durable product.

3. Mental Model

   MVP = smallest COMPLETE slice of the ONE core workflow [03] that delivers REAL value + lets you LEARN. "viable" (works for the job) AND "minimum" (cut the rest).
   ★ #1 trap: 3 months of INFRA before any user → built the wrong thing. start EMBARRASSINGLY SIMPLE.
     wk1 hardcoded prompt + CLI/Streamlit → 5 users · wk2–4 iterate + persist · wk4–8 EVALS [12] + COST [05] · later: gateway/routing/FT/polish
     (you may WRAP a model for the MVP to learn — but the wrapper ≠ the durable product [03]. learn first, then build the moat.)

   MVP SPEC (12 pieces): ICP [02] · user stories (JTBD [01]) · CRITICAL workflow (one, end-to-end [03]) · model choice [5] · RAG design [9] ·
     agent/tool design (least-agentic [10/10.05]) · EVAL plan [12.01] · COST model [05] · SECURITY posture [14] · DEMO script · 30-day build · 90-day launch

   SCOPE DISCIPLINE = saying NO: only the critical path of the ONE workflow. auth/settings/dashboards/multi-workflow/extra-integrations = LATER.
   DEMO SCRIPT (the product early on — validate [01]/sell [07]/raise [09]): painful BEFORE → AFTER on real data → TRUST features (citations/approval) → outcome (time/$ saved) + CTA
   30/90: 30d = embarrassingly-simple core workflow for design partners + first eval examples · 90d = first PAYING users + eval harness + cost instrumentation + first MOAT [06]

Mnemonic: build the smallest complete slice of the one core workflow, ship it embarrassingly simple in weeks (not after months of infra), and learn from real users — then add evals, cost instrumentation, and moat. The demo is your most-used artifact: painful before → after on real data → trust → outcome.

4. Hitchhiker's Guide

What to look for first: what's the one core workflow, and what's the smallest version that delivers real value? Everything in the MVP serves validating that workflow with real users.

What to ignore at first: infrastructure (gateway, routing, fine-tuning), polish, breadth, and every feature off the critical path. Build them after demand is validated.

What misleads beginners:

• Infra-first. Months of plumbing before users = the classic death — ship embarrassingly simple (00).
• Confusing MVP with the durable product. The MVP may be a wrapper to learn; the moat comes after (03).
• Scope creep. Auth/settings/dashboards/multi-workflow dilute the validation — cut to the core path.
• No eval/cost from the start. Deferring both means you can't iterate or price — build them by week 4–8 (Phase 12/05).
• Over-agentic MVP. Adding autonomous tool-use you don't need adds risk/cost — least-agentic that works (Phase 10).
• A demo that's all magic, no trust. Won't convert serious buyers — show citations/approval (03).

How experts reason: they scope the MVP to one core workflow for one ICP, start with a capable API model + minimal RAG/agent, ship an embarrassingly simple version to design partners in ~30 days, build the eval set and cost instrumentation by week 4–8, keep a tight security minimum (Phase 14), craft a converting demo, and use the 90-day plan to reach paying users and first moat. They say no to everything off the critical path.

What matters in production (of the MVP): real users doing the core workflow, evidence they'll adopt/pay, a working eval + cost number, a tight security posture, and a demo that converts — all reached fast.

How to debug/verify: can you ship the core workflow in ~30 days? Is anything in scope not on the critical path (cut it)? Do you have an eval set and cost-per-task by week 8? Does the demo show before→after→trust→outcome? Are real users (design partners) actually using it?

Questions to ask: what's the one core workflow and its smallest valuable version? what's the simplest model/RAG/agent that works? what's cut? when do evals + cost land? what's the security minimum? does the demo convert? what's the 30/90-day path to paying users?

What silently wastes the runway: infra-first building, scope creep, deferred evals/cost, over-engineering the MVP, and a magic-but-untrustworthy demo.

5. Warmup Readings

6. Deep Readings and External References

7. Key Terms

8. Important Facts

• An MVP is the smallest complete slice of the one core workflow that delivers real value and lets you learn — "viable" (works) and "minimum" (cut the rest) both matter.
• The #1 trap is infra-first — months of gateway/fine-tuning/polish before users; start embarrassingly simple (hardcoded prompt + CLI/Streamlit, ~5 users in week 1).
• You may wrap a model for the MVP to learn — but the wrapper is not the durable product; build the moat after validation (03).
• The MVP spec has twelve pieces: ICP, user stories, critical workflow, model choice, RAG design, agent/tool design, eval plan, cost model, security posture, demo script, 30-day build, 90-day launch.
• Scope discipline = saying no — only the critical path of the one workflow; auth/settings/dashboards/multi-workflow are later.
• Build the eval set and cost instrumentation by week 4–8 — early enough to iterate and price (Phase 12/05).
• The demo is the product early on — before→after on real data→trust features→outcome+CTA; you'll use it to validate, sell, and raise (07/09).
• 30 days = embarrassingly-simple core workflow for design partners; 90 days = paying users + eval harness + cost instrumentation + first moat (06).

9. Observations from Real Systems

• The fastest-learning startups shipped tiny first versions — a hardcoded prompt and a CLI/Streamlit in front of 5 users beat polished products built in isolation (00).
• Infra-first is a recurring grave — teams that built a gateway/fine-tuning stack before validating demand ran out of runway with no users.
• The demo carries early-stage AI companies — investors and customers buy the before→after story on real data; magic-without-trust demos stall with serious buyers (07/09).
• Evals built at week 4–8 (not launch) separate the iterators — they know when they're improving; vibe-only teams regress silently (Phase 12.01).
• "Least-agentic that works" MVPs ship faster and break less — adding autonomy you don't need adds cost, latency, and failure modes (Phase 10).

10. Common Misconceptions

11. Engineering Decision Framework

MVP DESIGN (from the AI-native design in [03]):
 1. SCOPE: pick the ONE critical workflow + ONE ICP [02]; write user stories (JTBD [01]). Cut everything off the critical path.
 2. STACK (minimal): capable API model [5] + the minimal RAG [9] + least-agentic tools the workflow needs [10/10.05]. Wrap-to-learn is OK.
 3. SHIP EMBARRASSINGLY SIMPLE: wk1 hardcoded prompt + CLI/Streamlit → ~5 design partners. Iterate on real feedback.
 4. DAY-ONE-ISH DISCIPLINES: build EVAL set [12.01] + COST instrumentation [05] by wk4–8; set a SECURITY minimum [14] (no secrets in prompts, PII, isolation, trust boundary).
 5. DEMO: script before→after(real data)→TRUST(citations/approval [03])→outcome(time/$ saved)+CTA. Practice it.
 6. 30-DAY: core workflow live for design partners + first eval examples.  90-DAY: paying users/pilots + eval harness + cost instrumentation + first MOAT [06].
 → If you're building infra before users, or scope exceeds the one workflow → STOP and cut.

12. Hands-On Lab

Goal

Write the full MVP spec (twelve pieces) for the AI-native design from 03, then ship the week-1 embarrassingly-simple version to a few real users.

Prerequisites

• The AI-native product design (03); ICP/beachhead (02); a way to ship a hardcoded-prompt CLI/Streamlit.

Steps

1. Write the spec: ICP, user stories (JTBD), critical workflow, model choice, RAG design, agent/tool design, eval plan, cost model, security posture, demo script, 30-day, 90-day plan.
2. Cut scope: list everything you're not building for the MVP (auth/settings/dashboards/extra workflows) — and confirm what's left is just the critical path.
3. Ship week-1: build the hardcoded-prompt CLI/Streamlit version of the core workflow; get it in front of ~5 real users.
4. Demo script: write and practice the before→after(real data)→trust→outcome+CTA demo (07).
5. Plan evals + cost: define the golden set/metric and the cost-per-task measurement to add by week 4–8 (Phase 12.01/05).
6. Security minimum: list the Phase 14 basics for the MVP (no secrets in prompts, PII handling, isolation if multi-user, trust boundary on actions).

Expected output

A complete MVP spec (twelve pieces), an explicit out-of-scope list, a shipped week-1 version in front of real users, a practiced demo script, and eval/cost/security plans — the buildable bridge from strategy to product.

Debugging tips

• If week-1 can't ship in days, your scope is too big — cut to the core workflow.
• If there's no eval/cost plan, you'll be unable to iterate or price (Phase 12/05).

Extension task

Define the trigger conditions for graduating from the wrapper-MVP to the durable AI-native build (workflow validated, demand confirmed) (03/06).

Production extension

Execute the 90-day plan: convert design partners to paying pilots, stand up the eval harness + cost instrumentation, and make the first moat investment (system-of-record/action ownership) (06).

What to measure

Time-to-first-ship, design partners using it, demo-to-commitment conversion, scope cut (features deferred), eval/cost readiness by week 8.

Deliverables

• A twelve-piece MVP spec + an explicit out-of-scope list.
• A shipped week-1 version in front of ~5 real users.
• A practiced demo script + eval/cost/security plans + a 30/90-day plan.

13. Verification Questions

Basic

1. What is an MVP (and what does "viable" vs "minimum" each mean)?
2. Why is infra-first the classic startup-killer?
3. What are the twelve pieces of the MVP spec?

Applied 4. Why can the MVP be a wrapper even though the durable product can't be? 5. When and why do you build the eval set and cost instrumentation?

Debugging 6. Your week-1 version will take two months. What do you do? 7. The demo wows but doesn't convert serious buyers. What's likely missing?

System design 8. Write the MVP spec for a document-automation product (workflow, model, RAG, eval, cost, security, demo, 30/90).

Startup / product 9. How does the 30/90-day plan turn a validation MVP into the seed of a durable product?

14. Takeaways

1. The MVP is the smallest complete slice of the one core workflow that delivers real value and lets you learn — viable and minimum.
2. Avoid the infra-first trap — ship embarrassingly simple (hardcoded prompt + CLI/Streamlit) to real users in week 1 (00).
3. The MVP may be a wrapper to learn; the moat comes after validation (03/06).
4. Build evals and cost instrumentation by week 4–8, keep a tight security minimum, and craft a converting demo (Phase 12/05/Phase 14).
5. Scope discipline is saying no — and the 30/90-day plan turns the MVP into paying users and first moat.

15. Artifact Checklist

• A twelve-piece MVP spec (ICP → 90-day plan).
• An explicit out-of-scope list (cut to the critical path).
• A shipped week-1 embarrassingly-simple version with real users.
• A practiced demo script (before→after→trust→outcome+CTA).
• Eval + cost + security plans (by week 4–8) and a 30/90-day plan.

Up: Phase 15 Index · Next: 05 — Cost Model and Unit Economics