Kitchenlab
For people building AI products without an AI team

Think the whole thing through before anyone writes code.

Kitchenlab is a conversation that turns an AI idea into a design brief a development team can use. Eight stations, one thread, no engineering background required.

Free during the pilot. Built on the Stanford d.school’s Your AI Mise en Place framework.

Start hereMenuone linewho forthe problemwhat changesPrepped
RequiredJourneylook + feelthe surfaceits limitswhen wrong
RequiredDatagrounded inwho owns ithow freshout of scope
Modelwhich modeltask shapecost + speedtune or not
Analyticswhat to logsuccess isearly warningreal usage
Safetykeep safeworst outputsensitive dataaccountable
Infrawhat's storedhow manymonitoringwho maintains
APIsconnects outexposestimeoutsif it dies

The Line: your eight stations. Set the Menu first, then take the rest in whatever order suits the idea.

How it works

One conversation. Eight stations. A brief at the end, whenever you want it.

01

Talk it through

You describe what you’re making. The assistant asks the questions a good technical lead would ask, one station at a time, in whatever order suits you. The thread is never cleared or split up, so nothing you said gets lost.

02

Decisions get pinned

Every decision you make lands in the Pantry as a short, editable statement. Fix the wording, dismiss a misreading. Each station shows exactly which questions are covered and which are still open, so you always know what would make it Prepped.

03

Plate the brief

When you’re ready, Kitchenlab writes a professional brief: your decisions in prose, the open questions listed plainly, and the roles the build implies. Come back later, talk more, and generate a new version.

The eight stations

The parts of an AI product that get skipped when nobody asks.

Each station covers four questions. Answer them all and the station is Prepped. Three are required before you plate a brief; the other five are yours if you want them. Cold stations aren’t failures, just open questions your brief will name.

The Menu
Required

What you're making and who for

  • What does this application do, in one sentence?
  • Who is it for?
  • What problem does it address?
  • What changes as a result of someone using it?
User Journey
Required

How the interaction feels

  • What does the interaction look and feel like?
  • What is the primary surface?
  • How does the user learn its limits?
  • What happens when the AI is wrong?
Data
Required

What it's grounded in

  • What data should this be grounded in?
  • Where does that data live, and who owns it?
  • How current does it need to be?
  • What's explicitly out of scope to know?
Model

The intelligence underneath

  • Which model or combination fits, and why?
  • Generation, classification, retrieval, or something else?
  • What are the cost and latency tolerances?
  • Foundation model, or fine-tune?
Analytics

How you'll know it works

  • What will you collect to assess success?
  • What does success look like numerically?
  • What tells you early that it is failing?
  • How will you see how people actually use it?
Safety

How you keep users safe

  • How do you keep users safe?
  • Worst plausible output, and what stops it?
  • What happens with sensitive data?
  • Who is accountable when it goes wrong?
Infrastructure

What it runs on

  • What data will you collect and store?
  • How many users, now and in 6–12 months?
  • How will you monitor performance?
  • Who maintains it, and at what cost?
APIs

What it connects to

  • What would you connect to?
  • What should your own API expose?
  • How are timeouts and rate limits handled?
  • What breaks if a dependency disappears?
The Brief

A document a developer will take seriously.

The kitchen language stays in the tool. What comes out is a plain, professional specification written in your own words, honest about what’s still undecided.

Summary. The app in one paragraph: what it does, who for, what changes.

One section per station. Your decisions as prose, quoting you where you said it well.

Open questions. Everything not yet addressed, framed as the next conversation to have.

Kitchen Staff. The roles this build implies, so you can scope a team.

Export as Markdown or PDF, or share a link. Also available as a ready-to-hand-off folder for coding agents.

Design brief
v2 · 11 Aug 2026

Curbside

Answers resident questions about bin days and collection rules

Summary

Curbside is a website widget for a district council of roughly 90,000 households. Residents ask about collection days and rules in plain language and get an answer sourced from the council’s published schedule. It removes the most common reason people phone the contact centre.

Data

Grounded in the collection calendar and the published rules pages, both owned by Waste Services. In the client’s words, it should “never state a collection date it cannot source.”

Open questions
  • Infrastructure: how many users, now and in 6–12 months?
  • APIs: what breaks if the calendar feed disappears?
Plated
Where it comes from

Built on the Stanford d.school’s Your AI Mise en Place.

The original worksheet asks you to lay out the seven ingredients of an AI solution before building anything. Kitchenlab turns that static canvas into a conversation that asks the questions, catches the gaps, and writes the answers up properly.

Request access

We’re opening the pilot in small groups. Leave an email and a line about what you’re making.

No newsletter. Just a note when you’re in.