Most tutorials hand you a model and a prompt and call it a product. A real planning meeting asks harder questions: can we ship a first cut by next month, will it actually help anyone, and what will it cost per user? An AI MVP is the smallest version of your idea that answers all three, and this playbook builds one you could finish in a weekend.

“If you are not embarrassed by the first version of your product, you shipped too late.”

Reid Hoffman, on shipping an MVP

Last Updated: July 2026 | Tested on: Python 3.14.6 (standard library only) | Difficulty: Intermediate | Reading Time: 23 minutes

Think of building an AI feature like opening a small food stall before you sign a lease on a restaurant. You do not buy a walk-in freezer and hire ten cooks on day one. You pick one dish, sell it from a cart, watch whether people come back, and only then decide what to build out. An AI MVP is that cart: one clear job, done end to end, put in front of real users fast enough that you learn something before the budget runs out. The order below is what separates a weekend prototype that becomes a product from one that becomes a graveyard branch nobody merges.

What Building an AI MVP Really Means

Here is what actually lands on your desk. A product manager, say a colleague named Anvi, comes back from a customer call and says “small businesses are terrified of the contracts they sign, can we build something that explains a contract in plain English?” Nobody mentions a model, a framework, or a Graphics Processing Unit (GPU).

Your job is to turn that sentence into something shippable, and the senior move is to say “yes, and here is the smallest version we can put in front of ten users next week.” Notice what building an AI MVP is not: it is not fine-tuning a model, it is not a benchmark score, and it is not a demo that only works on the three inputs you cherry-picked. And when the feature has to land inside a product that already exists, the adding AI to an existing app guide covers that path separately.

It is a working slice, measured against real examples, that you can defend in a review with a cost number attached.

The five steps that follow are the difference between “we spent a month and have a cool demo” and “we spent a weekend and have something users touched.” Frame the problem, cut the thinnest slice, write a small eval set, check the money math, then ship and iterate. The model is a swappable part in the middle. Get the frame around it right and you can change the model later without changing anything else.

Frame the Problem First: Do You Even Need ML?

The most expensive mistake in AI is reaching for a model when a handful of if-statements would do. Before you write a single prompt, ask the uncomfortable question: what does a dumb baseline score? A baseline is a set of plain rules a junior could write in an afternoon, and it does two jobs. It sometimes turns out to be good enough to ship as version zero, and even when it is not, it becomes the bar your fancy model has to clear to justify its cost. Say Anvay is asked to filter spam signups on a sports forum. Instead of training a classifier, he writes a rules-first baseline and measures it on a small labelled set first.

📄 rules_first_baseline.py: measure the dumb version before reaching for a model

# A rules-first baseline for "is this signup message a spam bot?"
# The point: measure a dumb baseline BEFORE reaching for ML.
LABELLED = [
    ("Win a FREE iPhone now, click http://bit.ly/xyz", True),
    ("Cheap loans, no credit check, act now!!!", True),
    ("Hi, I loved your article on pandas groupby", False),
    ("URGENT: verify your account or lose access http://scam.co", True),
    ("Can we reschedule tomorrow's standup to 11am?", False),
    ("Earn $5000 a week working from home, limited slots", True),
    ("Thanks for the invoice, paid it this morning", False),
    ("FREE FREE FREE crypto giveaway, send 0.1 ETH first", True),
    ("The paneer thali recipe you shared was delicious", False),
    ("Congratulations you WON a lottery you never entered", True),
    ("Quick question about the refund policy on my order", False),
    ("Buy followers cheap, guaranteed results, dm now", True),
    ("Meeting notes attached, see you Monday", False),
    ("Your package could not be delivered, pay fee http://x.co", True),
    ("Loved the talk at the meetup, let us connect", False),
]

SPAM_WORDS = {"free", "win", "won", "urgent", "click", "cheap", "guaranteed",
              "lottery", "crypto", "giveaway", "act now", "limited", "$"}

def looks_like_spam(text: str) -> bool:
    low = text.lower()
    hits = sum(1 for w in SPAM_WORDS if w in low)
    has_link = "http" in low
    excited = text.count("!") >= 2
    # simple rule: two or more independent signals means spam
    return (hits + has_link + excited) >= 2

tp = fp = tn = fn = 0
for text, is_spam in LABELLED:
    pred = looks_like_spam(text)
    if pred and is_spam: tp += 1
    elif pred and not is_spam: fp += 1
    elif not pred and not is_spam: tn += 1
    else: fn += 1

total = len(LABELLED)
correct = tp + tn
print(f"Rules-first baseline on {total} labelled messages")
print(f"  correct:       {correct}/{total}  ({correct/total:.0%} accuracy)")
print(f"  spam caught:   {tp}/{tp + fn}  (recall)")
print(f"  false alarms:  {fp}  (real messages wrongly flagged)")
print()
print("Verdict: good enough to ship as v0. No model, no GPU, no training run.")
print("Only reach for ML if this number is not good enough for the business.")

▶ Output

Rules-first baseline on 15 labelled messages
  correct:       14/15  (93% accuracy)
  spam caught:   7/8  (recall)
  false alarms:  0  (real messages wrongly flagged)

Verdict: good enough to ship as v0. No model, no GPU, no training run.
Only reach for ML if this number is not good enough for the business.

What happened here: Thirty lines of rules got 93 percent accuracy with zero false alarms, and it runs instantly for free. For a version zero spam filter, that ships. The one message it missed tells you exactly where a smarter model would earn its keep later, and now you have a number to beat. This is the discipline that separates engineers from tinkerers: you do not get to claim a model is worth its cost until you have shown the free baseline is not enough. Not every problem needs machine learning, and the ones that do are far easier to justify once you can point at the score the simple version could not reach.

Buy vs Build: API, Open Model, or Fine-Tune

Once you decide a problem genuinely needs a model, the next fork is how you get one. There are three doors, and for an MVP the right one is almost always the first. A hosted Application Programming Interface (API) means you rent a model over the network and pay per request. An open-weight model means you download the weights and run them on your own hardware. Fine-tuning means you take a base model and train it further on your own data.

People love to argue about this like it is a permanent identity choice, but for an MVP it is a sequence: start with the cheapest-to-start option, and only move down the table when you hit a wall you can name.

Read that table top to bottom, because that is also the order of pain. An MVP lives at the top row. You want to learn whether users care before you spend a single day on GPUs or labelling. The same logic applies to the code itself: build the thinnest end-to-end slice, which means one real input flowing to one real output, with the model hidden behind a single function you can swap. Aviraj wires the whole path first and stubs the model, so the plumbing is real even before the intelligence is.

📄 thinnest_slice.py: real interface, stubbed model, one swap away from production

# The thinnest end-to-end slice: clause text in, structured explanation out.
# The "model" is stubbed, but the INTERFACE is the real one you ship behind.
# Going from MVP to production later touches exactly ONE function.
from dataclasses import dataclass, asdict
import json

@dataclass
class ClauseExplanation:
    topic: str
    plain_english: str
    risk: str          # low / medium / high
    model: str         # which backend produced it, for logging and cost tracking

# ---- the only part that changes when you go from MVP to production ----
def call_model(clause: str) -> dict:
    """MVP stub. Later this is one real API call that returns the same shape.
    Fixing the shape now is what makes the swap a one-line change."""
    low = clause.lower()
    if "terminate" in low or "breach" in low:
        return {"topic": "termination", "risk": "medium",
                "plain_english": "Sets how either side can exit the deal."}
    if "indemnif" in low or "liable" in low or "liability" in low:
        return {"topic": "liability", "risk": "high",
                "plain_english": "Decides who pays when something goes wrong."}
    return {"topic": "general", "risk": "low",
            "plain_english": "A standard clause with no unusual obligation."}
# ----------------------------------------------------------------------

def explain_clause(clause: str) -> ClauseExplanation:
    try:
        raw = call_model(clause)
    except Exception:
        # a fallback path exists from day one, so one bad call never crashes the user
        raw = {"topic": "unknown", "risk": "unknown",
               "plain_english": "We could not analyse this clause. A human will review it."}
    return ClauseExplanation(model="stub-v0", **raw)

sample = "The Vendor shall indemnify the Client against all third party claims."
result = explain_clause(sample)
print("INPUT :", sample)
print("OUTPUT:")
print(json.dumps(asdict(result), indent=2))

▶ Output

INPUT : The Vendor shall indemnify the Client against all third party claims.
OUTPUT:
{
  "topic": "liability",
  "plain_english": "Decides who pays when something goes wrong.",
  "risk": "high",
  "model": "stub-v0"
}

What happened here: The whole product exists already. Text goes in, a clean structured explanation comes out, and there is a fallback so a bad response never crashes the user’s request. The only thing that is fake is the one function marked with the fence comments, and it returns the exact same shape a real API call will. When you are ready to plug in a real model, you rewrite that single function and nothing else moves.

That is the payoff of the thinnest slice: you prove the shape of the product before you pay for the intelligence, and the swap from stub to real model is a one-line diff, not a rewrite. Fallbacks like this one, along with routers and caches, are cataloged in the AI design patterns guide once you are ready to harden the slice.

A Golden Set on Day One

Here is the question that decides whether your MVP grows up: how do you know it works? “It looked good when I tried it” is not an answer, because you tried the three inputs you already knew it handled. A golden set is a small list of real examples, each paired with the answer the system must get right, written down before you build. It is the AI equivalent of a test suite, and twenty examples is enough to start.

Think of it like a tasting panel for a new dish: you decide what “good” means with a fixed set of judges before you start cooking, so you cannot fool yourself later. Aditi writes twenty contract clauses, each tagged with the topic the explainer must identify, then runs the stub against them.

📄 golden_set_eval.py: twenty examples that define “working” before any model exists

# 20 real-ish contract clauses, each tagged with the topic the explainer MUST get.
# You write this BEFORE the model. It is the test suite for your AI feature.
GOLDEN = [
    ("Either party may terminate this agreement with thirty days written notice.", "termination"),
    ("The Client shall pay each invoice within fifteen days of receipt.", "payment"),
    ("Late payments accrue interest at 1.5 percent per month.", "payment"),
    ("Neither party is liable for delays caused by events beyond reasonable control.", "force_majeure"),
    ("All work product created under this agreement belongs to the Client.", "ip"),
    ("Each party shall keep the other's confidential information secret for five years.", "confidentiality"),
    ("This agreement is governed by the laws of the State of Karnataka.", "governing_law"),
    ("The term renews automatically for one year unless cancelled in writing.", "renewal"),
    ("The Vendor shall indemnify the Client against third party claims.", "indemnity"),
    ("Services are provided as is with no warranty of any kind.", "warranty"),
    ("Neither party may assign this contract without prior written consent.", "assignment"),
    ("Total liability is capped at the fees paid in the last twelve months.", "liability_cap"),
    ("The Contractor is an independent contractor and not an employee.", "relationship"),
    ("Disputes shall be resolved by arbitration seated in Bengaluru.", "dispute"),
    ("The Client may audit the Vendor's records once per year.", "audit"),
    ("Either side may end the deal immediately for a material breach.", "termination"),
    ("Fees are non-refundable once the project has started.", "payment"),
    ("The receiving party shall not disclose trade secrets to competitors.", "confidentiality"),
    ("This document is the entire agreement and supersedes prior talks.", "entire_agreement"),
    ("Any changes must be made in writing and signed by both parties.", "amendment"),
]

# The MVP explainer is a keyword stub, no model yet. It returns the topic.
RULES = [
    (("terminate", "end the deal", "material breach"), "termination"),
    (("pay ", "invoice", "fees are", "non-refundable", "interest"), "payment"),
    (("beyond reasonable control",), "force_majeure"),
    (("work product", "belongs to"), "ip"),
    (("confidential", "trade secret", "disclose"), "confidentiality"),
    (("governed by", "laws of"), "governing_law"),
    (("renews", "renewal"), "renewal"),
    (("indemnif",), "indemnity"),
    (("warranty", "as is"), "warranty"),
    (("assign",), "assignment"),
    (("liability is capped", "total liability"), "liability_cap"),
    (("arbitration", "dispute"), "dispute"),
    (("audit",), "audit"),
]

def explain(clause: str) -> str:
    low = clause.lower()
    for keys, topic in RULES:
        if any(k in low for k in keys):
            return topic
    return "unknown"

passed = 0
misses = []
for clause, expected in GOLDEN:
    got = explain(clause)
    if got == expected:
        passed += 1
    else:
        misses.append((expected, got, clause))

print(f"Golden set: {len(GOLDEN)} clauses, written before any model code")
print(f"Stub explainer passes {passed}/{len(GOLDEN)}  ({passed / len(GOLDEN):.0%})")
print()
print("Gaps the golden set just exposed (your to-do list, not a surprise in prod):")
for expected, got, clause in misses:
    print(f"  want={expected:<16} got={got:<8} {clause[:44]}...")

▶ Output

Golden set: 20 clauses, written before any model code
Stub explainer passes 17/20  (85%)

Gaps the golden set just exposed (your to-do list, not a surprise in prod):
  want=relationship     got=unknown  The Contractor is an independent contractor ...
  want=entire_agreement got=unknown  This document is the entire agreement and su...
  want=amendment        got=unknown  Any changes must be made in writing and sign...

What happened here: The stub scores 85 percent, and the three it missed are printed as a to-do list rather than discovered later by an angry user. This is the whole value of a golden set: it converts a vague feeling of "seems fine" into a hard number, and it tells you precisely where the product is weak. When you later swap the stub for a real model, you run the exact same script and instantly see whether the model beat 85 percent or made things worse. Twenty examples took Aditi twenty minutes to write, and they now guard every change she ships. Skipping this step is how teams end up arguing about quality with opinions instead of numbers.

The Cost Ceiling: Unit Economics Before Launch

An AI feature that users love and that loses money on every request is not a product, it is a countdown. Before launch you owe yourself one spreadsheet-sized calculation: what does one unit of usage cost me, and does the price I charge cover it? This is unit economics, and it is the same math a chai stall owner does in their head before they set a price. For the contract explainer, one unit is one document, and one document is a handful of clauses each costing a bit of input and output. Anvi runs the numbers against a simple pricing plan.

📄 unit_economics.py: does the money math close before you ship?

# Does the money math close BEFORE we launch the contract-clause explainer?
# Dated placeholder prices (per 1M tokens), current at the time of writing (mid-2026).
INPUT_RATE = 0.60    # dollars per 1M input tokens, a mid tier model
OUTPUT_RATE = 2.40   # dollars per 1M output tokens

# One contract has about 12 clauses. Each clause plus instruction is roughly
# 220 input tokens in and 90 output tokens back.
CLAUSES_PER_DOC = 12
in_per_clause = 220
out_per_clause = 90

cost_per_clause = (in_per_clause * INPUT_RATE + out_per_clause * OUTPUT_RATE) / 1_000_000
cost_per_doc = cost_per_clause * CLAUSES_PER_DOC

# Business plan: free tier is 5 docs a month, paid plan is 9 dollars for 100 docs.
FREE_DOCS = 5
PAID_PRICE = 9.00
PAID_DOCS = 100

print(f"Cost per clause:                 ${cost_per_clause:.6f}")
print(f"Cost per document (12 clauses):  ${cost_per_doc:.4f}")
print()
print(f"A free user (5 docs/mo) costs us:      ${cost_per_doc * FREE_DOCS:.4f}/mo")
print(f"A paid user (up to 100 docs/mo) costs: ${cost_per_doc * PAID_DOCS:.4f}/mo")
margin = PAID_PRICE - cost_per_doc * PAID_DOCS
print(f"Paid plan price ${PAID_PRICE:.2f}  ->  gross margin ${margin:.2f} ({margin / PAID_PRICE:.0%})")
print()
# Cost ceiling: a paid user maxes out AND we add a second review pass (double cost).
worst = cost_per_doc * PAID_DOCS * 2
print(f"Cost ceiling (100 docs + a review pass): ${worst:.4f}, margin still ${PAID_PRICE - worst:.2f}")
print()
print("Verdict: model cost is a rounding error next to the price. The math closes.")
print("If it had not, you learn it now on a spreadsheet, not after launch on an invoice.")

▶ Output

Cost per clause:                 $0.000348
Cost per document (12 clauses):  $0.0042

A free user (5 docs/mo) costs us:      $0.0209/mo
A paid user (up to 100 docs/mo) costs: $0.4176/mo
Paid plan price $9.00  ->  gross margin $8.58 (95%)

Cost ceiling (100 docs + a review pass): $0.8352, margin still $8.16

Verdict: model cost is a rounding error next to the price. The math closes.
If it had not, you learn it now on a spreadsheet, not after launch on an invoice.

What happened here: A whole document costs less than half a cent to explain, so a nine dollar plan keeps 95 percent gross margin even if a user maxes out and you add a second review pass. That is a healthy MVP. The real value is not the happy answer, it is that Anvi knows it before launch instead of after. Run the same math with a frontier model that costs ten times more and a longer document, and you might find the free tier alone quietly bleeds money; better to learn that on a spreadsheet than from a scary invoice.

The prices here are dated placeholders, so copy live per-token rates from your provider before you trust a real budget. The mechanism, cost per unit versus price per unit, never changes.

Walkthrough: A Contract-Clause Explainer in a Weekend

Put the pieces together and you get a plan you could actually run on a Saturday and Sunday. The diagram below is the whole method in one picture: a loop, not a straight line, because a good MVP is something you circle through as you learn.

Saturday morning is framing. Anvi's idea, "explain a contract in plain English," becomes a scoped job: take one clause, return its topic, a one-line explanation, and a risk flag. You confirm a model is actually needed, since a pure keyword approach clearly cannot understand novel clauses, but you still keep the keyword version as your baseline and fallback. Saturday afternoon is the thinnest slice: the explain_clause function with a stubbed model, wired end to end so text flows in and structured output flows out. Saturday evening is the golden set: twenty clauses with their expected topics, giving you the 85 percent baseline number to beat.

Sunday is where the model arrives. You swap the stub for a hosted API call, the cheapest door from the buy-versus-build table, keeping the exact same return shape so nothing else changes. You rerun the golden set and check the score went up, not down. You run the unit economics so you can defend the cost in Monday's review. Then you ship the slice to ten friendly users and watch.

Every complaint or wrong answer becomes a new example in the golden set, which sends you back around the loop to iterate. Notice what you did not do this weekend: you did not fine-tune anything, you did not stand up GPU servers, and you did not polish a settings page nobody asked for. You shipped the smallest honest version and let real use tell you what to build next.

Common Mistakes

Best Practices

Frequently Asked Questions

Interview Questions on Building an AI MVP

Interviewers rarely ask for definitions. They ask what happens in situations like these.

Q: A product manager hands you an AI feature idea. What is your first step?

Frame it before touching a model: write the one-sentence job the feature does for a user, then ask whether it needs machine learning at all. A page of rules that scores 93 percent is a baseline the model has to beat to justify its cost. That framing plus a rules baseline usually takes an afternoon and kills half of bad ideas cheaply.

Q: Why write a golden set before any model code?

Because "it looked good when I tried it" only tests the inputs you already expected. Twenty labelled examples written up front turn quality into a number you can rerun on every change: swap a stub for an API, change a prompt, change a model, and the score tells you immediately whether you moved forward or backward. It is the cheapest regression suite you will ever build.

Q: When would you move from a hosted API to an open model or fine-tuning?

Only when you hit a named wall. Privacy requirements or per-request cost at real volume justify self-hosting an open model; a consistent style or format that no prompt reliably produces justifies fine-tuning. Each step down the buy-versus-build ladder adds weeks and operational load, so the burden of proof is on the move, not on staying put.

Q: How do you defend an AI feature's cost in a review?

With unit economics on one slide: tokens per request times price per token, against revenue or savings per user, with a worst-case ceiling. If the math closes with margin, the feature is a product; if it loses money per request, it is a countdown. Doing that arithmetic before launch is the difference between a defensible decision and an apology after the first invoice.

Go deeper: the official Python documentation covers every edge case of this topic.

What Comes Next

You now have the whole AI MVP loop: frame the job, cut the thinnest slice, write the golden set, do the cost math, ship to ten real users, and feed every failure back into the set. The next step is picking the tools around that loop, and the AI tech stack guide walks three real case studies for exactly that decision. For every topic in order, visit the Python + AI/ML tutorial series home.

Related Posts

Previous: AI Design Patterns: Routers, Fallbacks, Caches, and Agents

Next: Choosing an AI Tech Stack: 3 Real Case Studies

Series Home: Python + AI/ML Tutorial Series