Building an AI SaaS MVP: Stack, Scope and First Users

Founders often arrive with a feature list built from a demo: chat, agents, integrations, dashboards. Almost none of it decides whether the product works. This is the playbook I use for AI MVPs: what to cut, which AI parts to build first, the stack, the guardrails that need to exist before the first user, and how to get those users.

What makes an AI SaaS MVP different?

An AI MVP has two risks a normal MVP does not: every use costs money, and the core output can be wrong. A normal SaaS feature behaves the same every time and costs almost nothing per click. A model call varies in quality and has a price per token, so two questions need answers before launch, not after: how often is the output good enough, and what does one use cost?

That changes the scope. You can skip settings pages, but you cannot skip a way to measure quality and a way to stop one user spending your margin. Those are part of the minimum.

What should you cut from the first version?

Cut everything that is not the one workflow your first customers need. Michael Seibel's Startup School talk on how to plan an MVP sums up the method in four lines: "Time box your spec", "Write your spec", "Cut your spec", and "Don't fall in love with your MVP!" The same deck advises talking to users before writing code.

Paul Graham's essay Do Things That Don't Scale is the permission slip for the "do by hand" rows: "you can sometimes get away with doing by hand things that you plan to automate later." An import you run yourself for the first ten customers is a better MVP feature than an integration nobody has asked for.

Which AI parts should you build first?

Build the single AI step that produces the result customers pay for, and make it measurable. Anthropic's guidance on building effective agents recommends "finding the simplest solution possible, and only increasing complexity when needed", and notes that for many applications, "optimizing single LLM calls with retrieval and in-context examples is usually enough."

In practice, the first AI build is usually:

• One well-prompted model call with structured output your code validates.
• Retrieval over the customer's own data, if the answer depends on it. ScanX, an AI note-taking app I built, is an example: it chunks and embeds uploaded PDFs, retrieves only the passages that match a question, and cites the source pages so users can check each answer.
• A small [evaluation set](/blog/ai-agent-evaluation): real examples with expected results, re-run whenever the prompt or model changes.
• Logging of every request with its cost, so you know what a customer costs to serve.

Agents, multi-step automation and fine-tuning come later, once the single step works and you know where it fails.

Which stack should an AI SaaS MVP use?

Use a stack you can ship and debug quickly, with as few moving parts as possible. Mine, for most AI MVPs:

The ScanX case study explains the reasoning for two of these: server components keep API keys and the retrieval call server-side, and Convex stored the vectors alongside application data instead of needing a separate vector database at that scale. The exact choices matter less than keeping them few. Every extra service is another thing to configure, monitor and pay for before you have a customer.

Which guardrails must exist before the first user?

Four guardrails belong in the MVP, because adding them after an incident costs far more than building them first.

• Keys stay on the server. Never in client code. My post on protecting API keys in AI web apps covers the proxy, rate limits and leak response.
• Per-user cost caps. Meter the cost of every call and enforce a budget per plan. The design is in how to cap LLM costs per user.
• Reliable streaming states. Waiting, streaming, stopped and failed, with retry. See streaming LLM responses in Next.js.
• An evaluation set. Even twenty real examples tell you whether a prompt change helped or hurt.

Prices for model calls are public, so you can estimate cost per use before launch. As of late 2026, Anthropic's models overview lists Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens, with Haiku 5.5 from $0.10 and $0.50. Multiply by a typical request's tokens and expected uses per customer, and compare it with your price.

How do you get the first users?

You recruit them yourself, one at a time. Seibel's deck defines launch plainly: "Launch simply means to start getting customers." Graham's essay is blunter: "The most common unscalable thing founders have to do at the start is to recruit users manually."

What that looks like for an AI product:

• Go back to the people you interviewed while writing the spec, and offer them early access.
• Onboard each one personally: set up their data, watch them use the core workflow, and note where the AI output disappoints.
• Charge from the start, even a small amount. Willingness to pay is the signal an MVP exists to find.
• Review their AI outputs weekly, add failures to the evaluation set, and fix the most common one.
• Only then decide what to build next, using what those users asked for, not the original feature list.

The essay's other piece of advice applies too: "take extraordinary measures not just to acquire users, but also to make them happy." With an AI product, part of making them happy is fixing bad outputs quickly and visibly.

How long does it take, and what does it cost?

It depends on the workflow, the data and how much already exists, which is why I scope each MVP on a call rather than quoting a standard figure. A time-boxed spec is what keeps it predictable: decide the deadline first, then cut until the scope fits. For market rates when hiring, see how much it costs to hire an AI developer. For who should build it, my guide to what an AI full stack developer does describes the role that covers every layer of an MVP.

Work with me

I build AI SaaS MVPs end to end: scoping the one workflow, building it on a lean stack, and putting in the cost, key and quality guardrails before launch. See SaaS MVP development and full-stack development, or browse my work and book a scoping call.