Free tool · runs in your browser

Write a one-page brief a developer can build from

A two-line request gets you a build that misses. Forty pages don't get read. Nine short sections force the decisions only you can make: who it's for, what it must do first, what it must not do yet and how you'll know it's finished. Fill them in, fix what the checks flag, then copy, download or print the page.

What you type is saved in this browser only. Nothing is sent to us.

Project name

0/9 sections · 0 words

Fill in the sections; the checks appear as you type.

1. Goal

One sentence on what this is for, and how you'll know it worked.Name the problem it removes, then a number you can check in a month.

2. Users

Who uses it, three roles at most, one line each with what they can do.Role - what they do. If you have more than three, the rest belong in a later version.

3. Main journeys

The two or three things people will actually do, step by step, in plain words.One journey per line. Start each with who does it.

4. Data

What is stored, where it comes from, and who is allowed to see it.Write one "sees only" sentence per role. Mention existing data and attach a real sample.

5. Must have for version 1

The shortest list that makes it useful on day one.If a line could wait a month without anyone being stuck, move it to Not now.

6. Not now

What must not be built yet, even if apps like this usually have it.An AI coding tool adds extras unless told not to. Each one is code somebody has to check.

7. Connections

Other systems it has to talk to: email, calendars, payments, your existing tools.Say whether you already have an account, and whether it reads, writes or both.

8. Done means

Acceptance checks. One per line, each plainly true or false when you try it."A patient can book in under a minute on a phone" can be tested. "Fast and easy to use" can't.

9. Limits and handover

Budget and how it's paid, the date, languages, laws that apply, and where the code and accounts live.Code in your repository from day one. Hosting, domain, email and payment accounts in your company's name.

Your page

DEVELOPER BRIEF

1. GOAL
   (not filled in)

2. USERS
   (not filled in)

3. MAIN JOURNEYS
   (not filled in)

4. DATA
   (not filled in)

5. MUST HAVE FOR VERSION 1
   (not filled in)

6. NOT NOW
   (not filled in)

7. CONNECTIONS
   (not filled in)

8. DONE MEANS
   (not filled in)

9. LIMITS AND HANDOVER
   (not filled in)

Written with biz59.net/tools/developer-brief · 2026-10-10

How to use the page

Send it before you ask for a price. A good developer answers with questions, and those questions are the first real work on your project. If the developer builds with AI tools, the page is also what their coding agent works from, and an agent reads it literally: where a person would stop and ask, it picks something plausible and keeps going. That is why the checks here are strict about adjectives and about lines that can't be tested.

The sections, the clinic example and the reasoning are from how to brief a contract developer in the AI era. When the build comes back, go through section 8 line by line, then run the launch checklist before real users log in.

The checks look for words and patterns; they don't understand your project. Treat a flag as a question, not a verdict. More free tools: biz59.net/tools.