Building an AI MVP

Here is the thing that will save you three months: an AI MVP is not about the AI. It is about validating the job-to-be-done. The question you are actually trying to answer is not “can I get a language model to do this task” — you can almost certainly get a language model to do the task. The question is “do real people have this problem badly enough that they will change their behavior to use your product.” The AI is an implementation detail. The insight is the product.

Most first-time AI founders invert this. They spend six weeks tuning prompts, building out a fine-tuning pipeline, wiring up RAG, and debating model selection before they have a single user who has tried it twice. By the time they talk to real users, they have too much invested in the technical approach to update clearly on the feedback. The MVP ends up validating the founder’s assumptions rather than reality.

This is a guide for doing it the other way around.

What an AI MVP Actually Is

An MVP is not a small version of your product. It is a learning instrument. Its job is to answer a specific question — usually “does this solve a real problem for real people” — with as little irreversible investment as possible.

For an AI product, the irreversible investments are things like: custom fine-tuning runs, a complex orchestration architecture, a multi-model routing layer, a proprietary dataset pipeline. These are all things you should not be building until you have validated the core. They take weeks to build, they create path dependency, and they are almost always premature.

The right AI MVP is the minimum thing that lets a real user experience the core value exchange and tell you whether it worked for them. In most cases that is: a prompt, a thin interface, and a mechanism to collect feedback. That is all. Everything else is optimization of something you have not yet proven is worth optimizing.

Time to ship a first version: two to five days, not two to five weeks. If it is taking longer than that, you are building the wrong thing.

The Wizard of Oz Approach: Simulate AI With Humans First

Before you write any code at all, consider whether you can fake the AI entirely.

The Wizard of Oz method is named after the scene where Toto pulls back the curtain: the “wizard” is a person manually operating the levers. In product terms, you build the user-facing interface — the input form, the output display, the overall experience — but behind the scenes a human (usually you) is manually doing the thing the AI would do.

This sounds absurd. It is also extremely effective.

What you learn from a Wizard of Oz test in two days would take you four weeks to learn from a working prototype, because you learn it before you have written anything you would be reluctant to throw away. You learn whether users understand the interface, whether they phrase their inputs in the way you assumed, whether the output format you designed actually communicates what they needed, and most importantly, whether they come back.

The operational overhead is real — you may be manually responding to inputs at 11pm — but cap it at 20-30 users and a week of runtime. You are not building a service, you are running a test. Typeform as input, email as the response channel, and a Google Sheet to track it all is enough infrastructure to run a valid Wizard of Oz test for most B2B use cases.

If the Wizard of Oz test does not produce users who tell other people or ask to keep using it, stop. Do not build the AI version of something nobody wants automated.

What to Validate Before Writing a Single Line of Code

There are three questions you need real-world evidence on before you build anything:

1. Is the problem real and recurring? A problem someone has once a year does not support a product, no matter how well the AI solves it. You are looking for something that happens at least weekly, ideally daily. Talk to 15 people who fit your target profile. Ask when they last had the problem, what they did about it, and how much that cost them in time or money. Do not ask whether they would use your product. That question produces noise. Ask about the past.

2. Is the current solution genuinely bad enough? If people are mostly fine with how they handle it today, you do not have a market. You need the existing solution to be visibly painful — they are doing it manually when they hate manual work, or they are using a tool that is a bad fit, or they are just not doing it at all because it is too hard. The worse the current solution, the lower the bar your MVP needs to clear.

3. Will they act? This is the hardest one to test without a working product, but you can approximate it. Create a waitlist page with a specific value proposition. Run a small amount of paid traffic at it. A 15-20% email signup rate from cold traffic indicates something real. Zero signups after 300 visitors is a signal worth listening to. Alternatively, ask people in your discovery calls to introduce you to one colleague who has the same problem. If they do, the problem is real. If they can’t think of anyone, you may have a one-person problem.

None of this requires code. All of it should happen before you touch a keyboard for anything other than a landing page.

The Minimal AI MVP Stack

Once you have validated enough to justify building, the stack for a minimal AI MVP is genuinely minimal.

The prompt. One system prompt that defines the task, the output format, and any constraints. Spend real time on this. A well-engineered prompt is doing most of the product work. Store it in version control from day one, not in a Notion doc or a database field you update ad hoc.

The interface. For most use cases: a text input, a button, and an output display. Vercel v0 can generate this in fifteen minutes. If you need user accounts, Clerk has a free tier and takes an hour to wire up. Resist the urge to design. Wireframe functionality is correct for an MVP. Users evaluating whether the AI output is useful are not paying attention to your color scheme.

The feedback mechanism. This is the piece most people skip and it is the piece that matters most. Minimum viable: a thumbs up / thumbs down button attached to each output. Better: a free-text field that appears when they click thumbs down. Best: a structured question like “What would you change about this output?” You need this to learn anything from usage. A product that runs but collects no feedback is not an experiment, it is just a product nobody is paying for.

Infrastructure. Railway or Vercel for hosting. OpenAI or Anthropic API keys. A Postgres database if you need persistence (Supabase gives you one free). Langfuse in front of your API calls to log every input and output without building logging yourself. Total monthly cost at MVP scale: under $50.

That is the whole stack. You do not need Kubernetes. You do not need a vector database. You do not need a model router.

What NOT to Build in Your MVP

This list is more important than the previous one, because the natural instinct when building an AI product is to build too much.

Do not fine-tune. Fine-tuning is expensive, slow, requires labeled data you do not have yet, and solves a quality problem you have not proven exists. Prompt engineering with a frontier model will outperform a poorly fine-tuned smaller model on almost every task. Fine-tune after you have 1,000 real user interactions to learn from, not before.

Do not build complex orchestration. Multi-agent pipelines, chains of specialized models, dynamic routing based on input type — all of this is pre-optimization. Start with a single LLM call. You will be surprised how much you can do with one well-designed prompt. Add complexity only when you have a specific failure mode that proves you need it.

Do not build custom evals. You do not have a golden dataset yet because you do not have enough real usage. Evals built on synthetic examples tell you almost nothing. Collect 100 real user inputs first, label them, then build your eval suite.

Do not build multi-model routing. GPT-5.3 Instant or Claude Sonnet 4.6 for everything. Make one model decision and move on. Model selection is an optimization problem; you are not at the optimization stage.

Do not build an admin dashboard. You are the admin. Look at the database directly. Run SQL queries. Read the logs in Langfuse. An admin dashboard is what you build after the product is working.

How to Pick Your First Prompt: The Single-Prompt MVP

The most common mistake in prompt architecture is trying to do too much in one prompt. The second most common is using multiple prompts when one would do.

For a first version, find the single most valuable transformation your product makes. Not the whole workflow — the one step where a user’s situation changes meaningfully. If you are building a job description tool, it is not “generate a complete job posting” — it is “translate a raw list of responsibilities into language that attracts the kind of candidate we want.” That specific transformation is your first prompt.

Write it as if you were briefing a smart contractor who has never done this work. Give them context, constraints, an example of good output, and explicit instructions about what to do when the input is ambiguous or incomplete. Do not rely on the model to infer your preferences — state them.

Test it on 30 examples yourself before showing it to anyone. You are looking for the failure modes, not the successes. For every input where the output is wrong, add a constraint to the prompt that addresses it. Do this until you cannot find failures on reasonable inputs.

One good prompt is a product. Twelve mediocre prompts chained together is a debugging nightmare.

Getting Your First 10 Users to Try It

Ten users who try your MVP and give you real feedback are worth more than a thousand impressions on a landing page. Here is how to get them.

Use your existing network first. Post in a Slack community or Discord server where your target users hang out. A genuine “I built this, would five people be willing to try it and give me 20 minutes of feedback” post converts better than any pitch. You need five direct conversations in the first week, not a marketing funnel.

Find the watering holes. Where do your target users already spend time online? Indie Hackers, relevant subreddits, niche LinkedIn groups, industry Slack workspaces. Post something genuinely useful there — a short analysis, a useful observation, something that demonstrates you understand their world — then mention what you are building. Do not lead with the product.

Direct outreach beats everything. Identify 20 people who fit your target user profile exactly. Send them a cold email that is three sentences: who you are, what you built, why you think they specifically would have useful opinions on it. No pitch, no hyperbole. Ask for 15 minutes. A 20-30% response rate on cold outreach for early product feedback is achievable if the message is focused and honest.

Do not launch on Product Hunt yet. You are not ready. You want people who will give you honest negative feedback, not an audience who is primed to be impressed.

What to Measure: Is the AI Output Actually Useful?

Vanity metrics for AI products are especially dangerous because the model will always produce something. The question is whether that something is useful.

The metrics that actually tell you whether the product is working:

Output acceptance rate. What percentage of users take action on the AI output — copying it, saving it, using it downstream — versus abandoning it or immediately editing it substantially? This is your core quality signal. Track it explicitly.

Completion rate. What percentage of users who start a session complete it? If users are dropping off before seeing an output, the problem is in the input experience or latency. If they are dropping off after seeing the output, the problem is quality.

Return rate. Do users come back within 7 days? A tool that solves a recurring problem should see return usage. Low return rate on a tool that targets a recurring problem is a signal that the output was not useful enough to remember.

Qualitative signal from the feedback field. Read every piece of free-text feedback personally. Do not aggregate it or route it to a Notion database you check monthly. In the first 8 weeks, founder-reads-every-piece-of-feedback is the correct process.

Do not measure: time on site, page views, sign-up conversions, or social shares. These tell you about distribution, not value.

When to Iterate vs. When to Pivot

After your first 10-20 users, you will have one of three situations.

The output quality is consistently wrong. Users say the AI does not understand the task, or it misses something obvious, or it produces outputs they would never use. This is almost always a prompt problem, not a model problem. Iterate on the prompt before drawing conclusions. Collect the specific failing examples, diagnose what they have in common, and fix the prompt systematically. Do this for at most two to three weeks before reassessing.

The output quality is fine but users do not come back. This is the harder case, because it means the problem framing may be off. Either the problem is not recurring enough to drive return usage, or you are solving the wrong step in the workflow. Do more user interviews. Ask specifically: “If you had this tool available for the next month, when would you use it?” The answer often reveals that the problem you are solving is adjacent to the real problem but not quite it.

Users are coming back and referring others. This is the signal to invest. Now you can justify spending two weeks improving the prompt, building the evaluation suite, and adding the features that keep coming up in feedback. You have earned the right to optimize.

If after 20 genuine users and 4 weeks of iteration you do not have at least 5 people who use it weekly, the correct move is usually to pivot the use case, not rebuild the technology. The technology is probably fine. The problem framing is wrong.

Common AI MVP Mistakes

Over-engineering the infrastructure. Founders with engineering backgrounds default to building. Three days into an AI MVP and there are database migrations, a message queue, a custom eval framework, and a Terraform configuration. None of that is the product. The product is the interaction between the user’s input and the AI’s output. Keep the infrastructure boring until there is a reason not to.

Picking the wrong use case. The worst category for AI MVPs is tasks where quality matters extremely but verification requires expertise the user does not have. Legal document drafting is the textbook example: the model produces something plausible, the user cannot tell if it is correct, they rely on it anyway, and eventually something breaks. If your users cannot easily tell whether the AI output is good or bad, you do not have a feedback mechanism, and you cannot improve. Pick use cases where the quality of output is immediately obvious to the user.

No feedback loop. A product that users can use but cannot react to is a black box. Without a feedback loop, you are running your MVP blind — you have usage data but not quality data. The feedback mechanism is not a nice-to-have for a later iteration. It is required for the MVP to function as a learning instrument.

Treating the AI as the moat. If your entire pitch is “we use AI to do X,” anyone can reproduce it in a week. The moat in an AI product is the dataset you accumulate, the workflow you integrate into, the network effects you build, or the trust you establish with a specific community. Start thinking about what the durable advantage is from day one, because it is not the model.

The Two-Week AI MVP Plan

Week one: customer discovery and Wizard of Oz. Fifteen user interviews. A fake version running on manual operations for 10-15 test users. Feedback collected and read personally.

Week two: first real version. One system prompt. A thin UI. Feedback buttons on every output. Langfuse logging every API call. Shared with the same 15 people who ran the Wizard of Oz test, plus five new people found through direct outreach.

After week two: you have real usage, real feedback, and a real decision to make. That is faster and cheaper than any other path to the same information. The AI is there. Use it to learn, not to impress.