Course A · Module A4 Build · Lesson 13 of 17

Write the Build Brief

The one page you write before touching any AI builder is the page that decides whether your build actually works.

~12 min · Paper or a blank doc · Prereq: A12 Anatomy of an App

Most first builds fail before the first prompt. Not because the AI tool is bad — because the founder never decided exactly what they were making. They paste a vague idea, the AI guesses, the result is 70% right but 30% wrong in ways that are hard to fix, and two hours later they're rewriting everything. Your single win today: write a build brief — a one-page plain-English spec — before you open the builder. It is the biggest lever on output quality, and it takes 15 minutes.

Why a brief, not a prompt?

A contractor who builds exactly what their client describes is only as good as the description. Hand them "a nice kitchen" and you'll get a generic one. Hand them "a galley kitchen for a caterer: 12 ft run, double sink left of the range, 6 burners, no island" and you get something useful on day one.

Your build brief is the contractor's blueprint. The AI reads it once and makes decisions for every line of code it writes. Vague brief → vague app → expensive rework. Sharp brief → focused app → faster iteration.

The five questions your brief must answer

Must answer

  • Who is it for? One kind of user.
  • The ONE job it does. One sentence, one verb.
  • What goes in? The input (text, a form, a URL…).
  • What comes out? The output (a table, an email, a score…).
  • What does "done" look like? How you'll know it works.

Leave out for now

  • User accounts & login
  • Payment processing
  • Multiple features or tabs
  • Mobile app version
  • Anything you can add in version 2

The "leave out" column isn't permanent — it's version 2. The number-one mistake in a first build is scope creep before you have anything working. One narrow job, done well, is a win. A half-finished multi-feature app is not.

Fill in the template

Copy this into a doc or paste it directly into your AI builder as the opening of your prompt. Fill every blank before you proceed. If a blank feels hard, that difficulty is useful — it means you haven't decided yet, and it's better to decide now than at 11 pm staring at broken code.

Build Brief — fill every field
  1. Tool name: ________________________
  2. Who uses it: (one type of person) ________________________
  3. The one job it does: (one sentence, one verb — e.g., "takes a raw client note and returns a formatted follow-up email draft") ________________________
  4. Input: what the user types, pastes, or uploads to start ________________________
  5. Output: exactly what appears on screen when it works ________________________
  6. Done looks like: describe one test you can run right now — if you paste [this specific example], you should see [this specific result] ________________________
  7. Out of scope (v1): list anything you're deliberately leaving out so the AI doesn't add it ________________________
Scope test: read your "one job" sentence out loud. If it contains the word "and," split it in two and pick one. "Summarizes meeting notes and sends them by email" is two jobs. Pick the summary. Add email in v2 after the summary works.

Example brief

Here is a completed brief so you can see the bar to clear:

Example — completed build brief
  1. Tool name: Client Note Cleaner
  2. Who uses it: A solo consultant after a client call
  3. The one job: Takes a rough transcript or bullet-point note and returns a clean, professional summary formatted for the client record
  4. Input: A text box where the user pastes raw notes (50–500 words)
  5. Output: A formatted summary with three sections: Key decisions, Next steps (owner + date), Open questions
  6. Done looks like: I paste "call w/ alex — he wants proposal by fri, budget ~10k, worried about timeline" and I get a clean three-section summary I could email a client without edits
  7. Out of scope (v1): saving past notes, user login, exporting to PDF, email sending

Notice: no login, no history, no email — just the one transform. That's exactly what you paste into Lovable or Bolt next lesson. This brief is your A14 starting prompt.

Check yourself

Answer before opening — recalling it is what makes it stick.

Your brief says: "generates invoices and emails them to clients." What's wrong, and how do you fix it?

It contains two jobs. "Generates invoices" and "emails them" are separate features. Pick one for v1 — most likely the generator, since that's the harder UI piece. Add email sending in v2 once the invoice form works.

What's the purpose of the "out of scope" field?

It tells the AI what NOT to build. Without it, the builder may helpfully add login, history, or settings — all of which add complexity and breakage before you even have the core working. Explicit exclusions are as important as inclusions.

Why is "Done looks like: it works correctly" a bad definition of done?

It's untestable. "Done" must be a concrete, runnable test: a specific input that produces a specific output you can check right now. Vague done-criteria mean you'll never know if you're finished — and neither will the AI when it evaluates its own output.

Read this next (primary source)

Prompting best practices — Lovable Documentation. The official guide to writing prompts that produce focused, working apps — the same principles as the build brief, applied inside the builder. ~10 min. See RESOURCES.md for more.

I'm your teacher — share your brief. Paste your filled-in build brief and I'll tell you whether the scope is tight enough to build in one session, flag any fields that are still vague, and suggest a concrete "done looks like" test if you're stuck. Getting the brief right before you open the builder is worth 30 minutes of back-and-forth.

New words this lesson — build brief, scope — are defined in the course glossary. Keep it open.