Building an AI tool MVP

Getting a model to produce one good answer takes an afternoon. Getting it to produce good answers for strangers, at a cost you can predict, without falling over when a provider limits you, is the actual MVP. The model call is a few lines of code. The work is everything around it.

I designed and built the AI schedule assistant in FindPopups, a two-sided marketplace I made for a client, so this is a part of the stack I know well. This article is part of my guide to how to build an MVP. Everything else in a normal MVP still applies: sign-in, data rules, payments. The essentials of a SaaS MVP covers those.

API costs, in detail

Model APIs charge per token, separately for input (what you send) and output (what the model writes back). Prices are quoted per million tokens. A token is roughly a short word or part of a word, so a page of text is a few hundred tokens.

Here are Anthropic's current published prices for its Opus, Sonnet and Haiku models, plus OpenAI's cheapest text model for comparison. All prices are in dollars, because that is how both providers bill.

A worked example

Say each request sends 2,000 tokens (your instructions plus the user's input) and gets 500 tokens back. On Claude Sonnet 5.5 that is:

• Input: 2,000 tokens at $2 per million = $0.004
• Output: 500 tokens at $10 per million = $0.005
• Total: about $0.009 per request

At 1,000 requests a day, that is about $9 a day, or roughly $270 over 30 days. The same request costs about $0.018 on Opus 5.5 and under $0.001 on Haiku 5.5. That spread is why model choice matters more than almost any other cost decision.

Two things in that example are worth noticing. Output costs five times input per token, so long answers cost more than long prompts. And the instructions you send with every request are usually the same each time, which is where caching helps.

Three ways to cut the bill

• Prompt caching. Anthropic charges cache hits at a fraction of the base input price: 0.05x on Opus 5.5 and Sonnet 5.5, and 0.1x on other models. Writing to the 5 minute cache costs 1.25x. If your system prompt is long and stable, caching it pays for itself after one cache read.
• Batch processing. Anthropic's Batch API and OpenAI's Batch API both cost 50% less than standard requests. Results are not instant, so this suits overnight jobs, reports and bulk processing, not live chat.
• The cheapest model that passes. Start with a capable model to prove the job can be done, then run your evals against cheaper ones.

None of this matters if one user can send ten thousand requests. Cap usage per user per day from the start, store the token counts each response returns, and show users what they have left. That is a product decision as much as a technical one.

Rate limits and spend caps

Every provider limits how much you can send. At MVP volumes you will rarely hit the per-minute limits, but you will meet the account-level ones, especially on a new account.

Anthropic measures requests per minute, input tokens per minute and output tokens per minute, per model. Organisations move through Start, Build and Scale tiers based on usage history, and new organisations may start in an Evaluation tier with lower limits. Each tier has a monthly spend cap: $500 on Start, $1,000 on Build and $200,000 on Scale. On the Start tier, Claude Sonnet 5.5 is listed at 4,000 requests, 2,000,000 input tokens and 400,000 output tokens per minute. Cached input tokens do not count towards the input limit, which is another reason to cache.

When you go over a rate limit, the API returns a 429 error, usually with a retry-after header saying how long to wait. Hitting the monthly spend cap also returns a 429, but with no retry-after header and an error code of enforced_spend_limit_reached. Retrying will not help until the month resets or the cap is raised. If your app treats every 429 the same way, a spend cap will look like a long outage.

OpenAI measures requests and tokens per minute and per day. Usage tiers rise automatically with total credit purchases: Build at $5, Launch at $100 and Grow at $500, with monthly usage limits of $500, $5,000 and $200,000. OpenAI recommends exponential backoff with jitter, honouring the Retry-After header, and capping retries, and notes that failed requests still count towards your per-minute limit.

The practical upshot for an MVP:

1. Check your tier and spend cap before launch day, not on it.
2. Set your own lower spend limit in the provider's console so a bug cannot run up the bill.
3. Handle the spend cap differently from a rate limit.
4. Show users a clear message when the AI part is unavailable, and keep the rest of the product working.

Code that fails gracefully

Here is the shape I would use for a single AI feature in a Next.js app with Anthropic's TypeScript SDK. It caps usage per user, lets the SDK retry rate limits, records token usage and returns a friendly result instead of throwing at the user.

import Anthropic from "@anthropic-ai/sdk";
 
// The SDK retries 429s, 5xx and connection errors with backoff. Default is 2.
const client = new Anthropic({ maxRetries: 3 });
 
const DAILY_TOKEN_CAP = 200_000; // per user: set from your own cost sums
 
export async function summarise(userId: string, text: string) {
  const used = await tokensUsedToday(userId); // your own usage table
  if (used >= DAILY_TOKEN_CAP) {
    return { ok: false as const, reason: "daily-limit" };
  }
 
  try {
    const response = await client.messages.create({
      model: "claude-opus-5-5", // swap for a cheaper model once it passes your evals
      max_tokens: 16000,
      system: SYSTEM_PROMPT, // keep this identical between requests so it can be cached
      messages: [{ role: "user", content: text }],
    });
 
    await recordUsage(userId, response.usage.input_tokens + response.usage.output_tokens);
 
    const block = response.content.find((b) => b.type === "text");
    return { ok: true as const, text: block?.type === "text" ? block.text : "" };
  } catch (error) {
    if (error instanceof Anthropic.RateLimitError) {
      // Retries ran out, or the monthly spend cap was reached. Log it and tell the user.
      return { ok: false as const, reason: "busy" };
    }
    throw error;
  }
}

tokensUsedToday, recordUsage and SYSTEM_PROMPT are yours to write. Keep the API key on the server only. If the call runs in the browser, your key is public.

Evaluation before launch

The hardest part of an AI MVP is knowing whether the output is good enough. Trying a few prompts by hand and liking the results is not a test. Users will send things you never thought of.

Both main providers publish guidance on this. Anthropic's advice is to define measurable success criteria first, design evals that mirror your real-world tasks including edge cases, automate grading where you can, and favour more test cases with automated grading over a few hand-graded ones. OpenAI's guidance follows a similar loop: define the objective, collect a dataset that reflects real use, define metrics, run and compare, and keep evaluating on every change. It also recommends logging from the start so you can turn real interactions into test cases, and checking any model-based grader against human judgement before trusting it.

For an MVP, that comes down to something small and practical:

1. 1

   Write 20 to 50 real examples

   Inputs your users will actually send, including messy, short, long and off-topic ones. Real data beats invented data.

2. 2

   Decide what pass means for each

   An exact answer, a required fact, a format, a length limit, or a yes or no question a second model can check.

3. 3

   Script it

   A small script that runs every example and reports how many pass. Run it whenever you change the prompt or the model.

4. 4

   Add every failure you see in production

   Each bad answer a user reports becomes a new test case, so it cannot quietly come back.

// A minimal eval runner. Each case has an input and a check.
type EvalCase = { input: string; check: (output: string) => boolean };
 
const cases: EvalCase[] = [
  { input: "Market on Saturday 10am to 4pm, Old Market Square", check: (o) => o.includes("Saturday") },
  { input: "", check: (o) => o.length > 0 }, // empty input should still return something sensible
];
 
let passed = 0;
for (const c of cases) {
  const result = await summarise("eval-user", c.input);
  if (result.ok && c.check(result.text)) passed++;
}
console.log(`${passed}/${cases.length} passed`);

The pass rate you need depends on the cost of a wrong answer. A draft the user edits can be wrong sometimes. A figure the user relies on cannot.

What changes in the product design

AI features need a few things normal features do not:

• A way to see and fix the output. Show what the model produced and let users edit it, rather than acting on it silently.
• Honest loading states. Responses can take several seconds. Stream the answer if it is long, and show progress if it is not.
• A fallback. If the AI part is down or capped, the rest of the product should still work.
• Clear data handling. Say in your privacy policy that user input is sent to a model provider, and check the provider's data terms.

How long it takes

An AI tool MVP usually takes about as long as a normal MVP of the same size, plus time for evaluation. The prompt and the API call take days. Getting from a good demo to something consistently good enough for strangers takes longer, and that is the part to plan for. How long it takes to build an MVP has the general timelines. Before you add anything, check the cut list in what to cut from your MVP, because an AI feature that is decoration rather than the job is often the first thing to go.

Then put your scope through the MVP cost calculator, which has an AI tool option. For agency price ranges on AI-integrated MVPs, see what an MVP costs in the UK.