MVPSTUDIOSIDEAS · PRODUCTS · PEOPLE Start a conversationLet's talk
← Week 10: Assemble at scale: build Claude into your product SESSION 01 · TUESDAY

Put Claude to work inside your product

Tonight your product makes its first call to Claude: from your server, with a key you control, a reply you check and a person who decides.

THE CLAUDE APISPEND LIMIT FIRSTSTRUCTURED OUTPUTFAKE-RESPONSE TESTSFEATURE FLAG
Present slides Full screen, one slide at a time · 11 slides
TONIGHT 01

By the end of tonight you can

  • Explain how your app talks to Claude: your server, a key, a request, a response, your checks
  • Set up the Claude Console safely: spend limit first, a key per environment, the key in .env
  • Describe a Messages API request and response in plain English, including token usage
  • Ask Claude for structured output, validate it in code, and say when tool use fits
  • Build the AI slice behind a feature flag, with tests that use a fake Claude response

OUTPUT · AI slice working on staging behind a feature flag, with tests

THE IDEA 02

How an app talks to Claude

  1. YOUR SERVERYour product’s back end makes the call; the user’s browser never talks to Claude
  2. A KEYA secret from the Claude Console that proves the call is yours and bills your account
  3. A REQUESTThe model, standing instructions, the user’s text and only the data Claude needs
  4. A RESPONSEClaude’s reply, the reason it stopped, and how many tokens it used
  5. YOUR CHECKSCode checks the reply before anyone sees it; a person approves anything that matters

Claude suggests, your code checks, a person decides. That order never changes.

THE IDEA 03

Claude Code builds your product vs Claude runs inside it

Claude Code builds it

  • A tool at your desk that plans, writes and tests your code with you
  • You watch each step and approve its edits and commands
  • Its mistakes land in your repository, where tests and review catch them

Claude runs inside it

  • A call your product makes for users, many times a day, while you’re not watching
  • Each call uses tokens billed to your Console account, through your key
  • Its mistakes reach users unless your code checks the reply first

Tonight you use the first to build the second. Same Claude, different jobs, different safeguards.

SET-UP 04

Set up safely, in this order

  1. YOUR OWN ACCOUNTThe Console account you made in week 9, never shared; make one now if not
  2. SPEND LIMIT FIRSTCheck the monthly limit from week 9 (about £20 suggested) before any key exists
  3. A KEY PER ENVIRONMENTOne key for staging, another for production, named so you can tell them apart
  4. KEY IN .ENVLocally in .env, listed in .gitignore; on staging and production in the host’s settings
  5. IF IT LEAKSA key seen in a repo, a chat or a screenshot is leaked: replace it in the Console

Limit first, then keys. A key lives on the server, never in the browser, the repository or a prompt.

THE MESSAGES API 05

The Messages API in plain English

  1. MODEL AND LENGTHWhich tier (smaller and faster, or most capable) and the longest reply you allow
  2. SYSTEM PROMPTStanding instructions: role, context, rules with reasons, personality; your week 9 v1
  3. MESSAGESThe conversation so far; for TutorDesk, one message: the parent’s text and free slots
  4. RESPONSEClaude’s reply, plus why it stopped: it finished, or it hit your length limit
  5. USAGEInput and output tokens for this call: the numbers you turn into cost

Claude remembers nothing between calls. Everything it needs travels in each request.

WORKED EXAMPLE · TUTORDESK 06

TutorDesk: from a message to a slot proposal

Starting point

Send Claude the parent’s message and show the tutor whatever comes back.

Reframed

Send the message plus this week’s free slots. Claude returns JSON: learner, days, times, dates to avoid, one slot ID from the list, a question if unsure. Code checks it; the tutor taps.

Ask

  • What should the JSON say when the message isn’t a booking at all?
  • Why pick a slot ID from a list instead of writing a date?
  • What does the tutor see if the checks fail?
  • Which fields does your own feature need, and which can it drop?
THE IDEA 07

Structured output and tool use

  1. ASK FOR A SHAPEShow an example or a schema of the JSON you want, and ask for only that
  2. VALIDATE IN CODEValid JSON? Required fields present? Is the slot one we actually offered?
  3. FALL BACKIf any check fails, show something useful without AI: “please choose a slot”
  4. DESCRIBE TOOLSEach action Claude may ask for gets a name, a description and an input schema
  5. YOUR CODE DECIDESClaude can only ask; your code checks each request and runs only what you allow

If the data can travel in the request, you may not need tools. Start with the simplest design.

CLAUDE STUDIO 08

Plan and build the AI slice with Claude Code

Prompt for Claude
I’m building TutorDesk, a booking tool for independent tutors. I want to add our first Claude-powered feature, so tutors stop retyping messy parent messages into slots. The design is in product/08-ai-feature.md, product/09-ai-experience.md and ADR 0002.
In plan mode, plan the slice: a server-side call reading the key from the [KEY VARIABLE NAME] setting; the system prompt from [PROMPT FILE]; a JSON reply checked in code (the slot must be one we offered); a fallback; a feature flag, off by default; and tests that use a fake Claude response (valid, invalid, error, flag off). Wait for my approval.
When it’s built, report the commands you ran and their output, the usage from one real call on staging, and anything that failed or you’re unsure of.

Check the response

  • The call stays on the server; the key is read from settings
  • Fake-response tests cover valid, invalid, error, flag off
  • The report shows real usage numbers from one staging call
WORKSHOP · YOUR PRODUCT 09

Workshop: build the AI slice behind a flag

Set up the Console safely, then build your AI slice (or internal tool) with Claude Code in small loops, behind a flag that is off by default.

  1. Check your week 9 Console account and spend limit; make a staging key and store it safely
  2. Run the Studio briefing in plan mode; push back on one point, then approve
  3. Build in small loops; run the fake-response tests and read the diff after each
  4. Switch the flag on in staging only; make three real calls and record their token usage
  5. Break it on purpose (a wrong key, a non-booking message) and check the fallback appears
Deliverable

AI slice on staging behind a flag, tested; linked from product/08-ai-feature.md

GATE 10

AI slice rubric

  • The slice runs on staging with the flag on; with the flag off, no call to Claude is made
  • The key is read from server settings; none appears in the repository, browser code or prompts
  • A Console spend limit is set, and staging and production use separate keys
  • Claude’s reply is validated in code; an invalid reply or an error shows the fallback, live
  • Fake-response tests for valid, invalid, error and flag-off cases are shown passing
  • A person approves the proposal or draft before anything is saved or sent

HOMEWORK · Make sure product/evals/ holds your eval cases and threshold; bring usage from three real calls.

© 2026 MVP Studios Ltd. MVPAI™ and the MVP Founders Programme materials are original works of MVP Studios Ltd. All rights reserved. No copying, redistribution or commercial use without written permission. Course terms