Should your MVP have AI in it?

Nearly every founder brief we receive at Novek Labs now mentions AI. Based on what actually survives our discovery week, roughly a third of them should. That gap is not because the technology disappoints; the models and tooling in 2026 are genuinely good, and LLM features are part of our standard MVP toolkit. The gap exists because "should my product use AI" is the wrong question.

The right question is the one that governs every MVP decision: what must this product prove, and does AI serve the proof?

This post is the framework we use to answer it, along with the costs founders consistently underestimate and the architecture that keeps early AI bets cheap to change. It reflects what we have learned building AI-first products, adding AI features to conventional ones, and, more than once, talking a founder out of an AI feature that would have sunk their timeline for nothing.

Key takeaways

• If the AI interaction is the product thesis, it belongs in the MVP in its thinnest testable form: one model, one well-designed pipeline, no fine-tuning.
• If AI is a feature on top of a thesis that could be proven without it, it usually belongs in v2, after real users exist to ask for it.
• The real engineering cost of an LLM feature is not integration. It is evaluation: making the feature reliable across messy real-world input.
• Inference cost is a product decision, not an implementation detail. Model choice and caching strategy shape unit economics from day one.
• Whatever you build, assume the underlying model gets swapped within a year, and keep the abstraction layer thin enough to make that a small job.

The decision framework

AI belongs in the MVP when it is the product

If your pitch is "an assistant that drafts legal responses," "search that understands maintenance manuals," or "an agent that reconciles invoices," then the model interaction is the thing being tested. Cutting it would mean testing nothing. Build it.

But build the thin version. In practice that means:

• One model, accessed through its API. The major LLM APIs are good enough to prove or disprove almost any product thesis. Fine-tuning, custom serving, and multi-model routing are v2 optimizations pretending to be v1 requirements.
• One pipeline, designed carefully. Most of the quality in an early LLM product comes from unglamorous work: what context gets retrieved, how the prompt is structured, what happens when the model refuses or rambles. This is product design as much as engineering.
• Visible seams. Show users what the model saw and let them correct it. Early AI products earn trust through legibility, not through pretending to be infallible.

AI belongs in the MVP when it removes the biggest onboarding wall

Sometimes a single model-powered feature collapses the hardest step of adoption. Importing messy spreadsheet data. Generating a first draft so the user never faces a blank page. Mapping fields from a legacy export automatically. If your funnel analysis says the wall is what kills conversion, the feature serves the proof and earns its slot.

The test is honest counterfactual: would users get through onboarding without it? If yes, it can wait.

AI waits for v2 when it decorates

A chatbot in the corner of a marketplace MVP proves nothing about whether buyers and sellers show up. AI-generated product descriptions prove nothing about whether anyone wants the products. Decorative AI is this decade's version of the unnecessary native app: impressive in the demo, invisible in the retention data, and expensive in the schedule.

The tell is that the feature demos better than it retains. If the AI is what you show investors but not what users came for, it is decoration.

AI waits for v2 when it multiplies your unknowns

An MVP is an instrument for isolating one risk: does anyone want this? A model in the critical path adds unrelated risks on top: hallucination in front of your earliest and least forgiving users, latency that makes the product feel broken, inference costs that distort unit economics you have not measured yet, and an evaluation burden your six-week schedule did not budget for.

If the thesis can be proven without those risks, prove it without them. Then add intelligence to something people already want, with real usage data telling you where it helps.

And a word about the pitch deck

Investors in 2026 have seen a thousand thin wrappers. A product with real usage and no AI raises better than a product with AI and no usage. If the honest motivation for the feature is the deck, cut it and put the two saved weeks into getting users.

The costs founders underestimate

Three realities we price into every AI engagement, because they surprise people.

Evaluation is the real work

Getting an LLM feature working in a demo takes days. Making it reliable across the full messy range of real user input takes longer than the rest of the feature combined. Users paste in garbage, write in three languages, ask adversarial questions, and depend on outputs you did not anticipate.

Practical minimums we hold ourselves to even in an MVP: a test set of real-shaped inputs before launch, logging of every model interaction from day one, a defined failure behavior (what the user sees when the model output is unusable), and a human-visible escape hatch. Budget this or ship something you will be apologizing for.

Inference cost scales with success

A feature that costs pennies a day in testing can become a top-three line item at ten thousand users. The economics are steerable, but only if treated as a product decision: which interactions genuinely need the strongest model, what can run on a cheaper one, what can be cached, and what should not be a model call at all. We model this arithmetic during discovery, because a unit-economics surprise in month four is a strategy problem, not an engineering one.

The stack moves monthly

Model rankings reshuffle constantly. Whatever you build should assume the underlying model will be swapped at least once in the first year, either for quality or for cost. The insurance is cheap: keep every model call behind one thin internal interface, keep prompts in versioned files rather than scattered through the codebase, and keep the evaluation set runnable against any candidate model. Swapping then becomes a day of work instead of a rewrite.

Anti-patterns we see in the wild

• The roadmap-brief mismatch: an MVP brief where the AI feature list is longer than the user-problem description. Usually means the thesis is unsettled and AI is standing in for it.
• Fine-tuning first: reaching for training before prompt-and-retrieval has been exhausted. In our experience the thin pipeline gets further than founders expect, at a fraction of the cost and none of the lock-in.
• Agent maximalism: multi-step autonomous workflows in v1, where each step multiplies failure probability. Start with the single highest-value step, supervised.
• Invisible AI: model output presented as authoritative fact with no indication of source or confidence. This burns trust precisely with the early adopters you need most.

How this plays out in practice

Two composite examples from our own work, simplified:

AI as thesis. A founder wanted to prove that support teams would trust model-drafted responses to customer tickets. The MVP was almost nothing but the pipeline: retrieval over the company's help content, a carefully designed draft-and-cite flow, and an interface where agents approved, edited, or rejected drafts. No dashboards, no analytics suite, no integrations beyond one help desk. The reject rate was the entire product question, so everything served measuring it.

AI as premature feature. A marketplace founder arrived with "AI-powered recommendations" in the v1 scope. The marketplace had zero listings. We moved recommendations to v2, shipped search and browse, and the proof (do both sides show up?) arrived two months sooner. Recommendations became meaningful only after there was behavior to learn from, which is a nice example of the general rule: most AI features are v2 features because they feed on usage the MVP has not generated yet.

Frequently asked questions

Which model should my MVP use? The boring answer: the strongest general API model your unit economics allow, behind an abstraction that lets you change your mind. Model choice matters far less than pipeline design at MVP stage, and any specific recommendation in a blog post would be stale within a quarter.

Does adding AI change the MVP timeline? An AI-first product typically runs 7 to 10 weeks against 6 to 8 for a comparable conventional one, with the difference going into evaluation and reliability work rather than integration. The full timeline breakdown is in How long does it take to build an MVP?

Do I need my own training data to start? Almost never for v1. Retrieval over your existing content plus careful prompting covers most first products. Proprietary data becomes a moat later; at MVP stage the moat is learning speed.

What about building on AI coding tools instead of hiring anyone? For prototypes and demand tests, genuinely viable and we encourage it. For a production MVP with auth, payments, and real users' data, the constraint was never typing speed. It is knowing what to build, what to cut, and what will fall over. That judgment is what you are hiring.

How do you charge for AI features? Same as everything else: fixed scope, fixed price, agreed after a discovery week. Inference costs run through the client's own API accounts from day one, so the economics are transparent and nothing is marked up.

Where we land

Our default at Novek Labs: if AI is the thesis, it goes into the MVP in its thinnest testable form. If AI is a feature, it waits until there are users to ask for it. Either way the architecture stays boring and swappable, the evaluation gets budgeted honestly, and the model never gets to be the excuse for missing a launch date.

Not sure which side of the line your idea falls on? Describe it to us. We reply within 24 hours with a straight answer, including, when it is true, "you do not need AI for this yet."