Free tool · No email required

Project brief generator

Answer the questions and the brief writes itself in the panel below, as you type. There’s no email step, no account and no “we’ll send the full version”. The whole document is on the page, including the parts that make it uncomfortable.

It also does the thing no other brief builder does: it tells you which parts of your own brief are missing, what a vendor will have to guess in their place, and the questions they’ll send back before quoting. That gap between what you wrote and what they need is where quotes for the same project diverge by a factor of five.

Everything runs in your browser as plain templating. No model is called, so the same answers always produce the same document, and nothing you type is sent anywhere or seeded with our own material.

This page loads with a worked example already filled in, so you can see what the output looks like before typing anything. Northgate Physiotherapy is invented. It isn’t a client of ours, and nothing in it is drawn from anyone’s real project. Clear it and put your own in whenever you’re ready.

1. The project

Name the user and the outcome. “A booking tool” describes a thousand different quotes. 126/220

What kind of work is it
2. What exists today

This is the section that decides whether there’s data to migrate, and migration is the line underestimated most often.

A vendor who doesn’t know the problem will optimise the wrong thing, correctly. 299/700

Leave this blank and the delivery date becomes the only measurable thing in the project, so it’s the thing every trade-off gets resolved in favour of. 240/400

3. Users and roles

Every person who touches the product, including the ones who only approve things. Roles are the permission model, and permissions live in the data model rather than the interface.

4. Features

Tag each one must-have for launch or later. The second column is the one that does the work: it’s what stops a quote drifting, because whatever you leave off the page, each vendor fills in differently.

5. Third-party systems

Anything the product reads from or writes to. Reading and writing are different jobs at different prices, so tag each one.

6. Data and compliance

These change the architecture, the hosting region and the length of the review before launch. An explicit “none” is worth as much as a list.

Residency decides which rules apply and where the database is allowed to sit. This tool doesn’t interpret those rules, and neither should a brief: it records the fact and leaves the legal reading to somebody qualified to give it.

7. Platforms and scale

Five different amounts of work, not one. A brief that says “an app” has said almost nothing.

Guesses are fine, and the brief will call them guesses. The gap between the two numbers is what decides the architecture, so the pair matters more than either figure. Anything above 100,000,000 is clamped, and negative numbers become zero.

8. Timing, budget, decision

A date with a reason gets planned around. A date without one gets negotiated away, usually in the second meeting.

Budget band

These brackets are the price bands EdgeBrain publishes, so they’re one studio’s numbers rather than a market survey. Pick whichever bracket your own figure falls into, regardless of who you send the brief to.

An estimate in US dollars, not a quotation; the quote you get after scoping is fixed in writing before kickoff.

Zero means not stated. Clamped at 40.

9. What the vendor inherits

Whatever isn’t handed over gets built, and building it is a real line on the quote.

Completeness

89 / 100

Send it. A vendor can quote this without a discovery call first, and the questions below are the ones you will still get.

The score is addition, not judgement: 89 points earned out of 100available, shown row by row below. A half-answered section earns half its weight. The weights are ours, and they’re roughly proportional to how far a quote moves when the section is absent.

Completeness by section, showing the weight available, the points earned, and what is missing.
SectionPoints
What the software doesAnsweredOne sentence saying what it does and who for. It is the first thing read and the thing every other section is checked against.9 / 9
What exists todayAnsweredDecides whether there is data to migrate. Migration off a running system is the line underestimated most often, and by the widest margin.7 / 7
Users and rolesAnsweredRoles are the permission model, and permissions live in the data model rather than the interface. A role added after signature is a schema change.8 / 8
Must-have for launchAnsweredThe single largest driver of any number you are quoted. Everything else adjusts a total that this list sets.13 / 13
Explicitly out of scopeAnsweredExclusions are what stop a quote drifting. Whatever you leave off the page, each vendor fills in differently, which is where a factor of five comes from.9 / 9
Third-party systemsAnsweredEvery external system carries authentication, retries, rate limits and a sandbox that behaves differently from production.9 / 9
Data and complianceAnsweredPersonal, payment and health data change the architecture, the hosting region and the review that has to happen before launch.8 / 8
Platforms requiredAnsweredWeb, iOS, Android, an admin console and an API are five different amounts of work. A brief that says “an app” has said almost nothing.6 / 6
Success criteriaAnsweredA vendor who does not know what success looks like optimises for the delivery date instead, because that becomes the only measurable thing left.6 / 6
Expected scaleMissingRarely changes the price at low numbers and always changes it at high ones. It tells a vendor which architecture is honest.No numbers given. A vendor assumes low hundreds, which is fine until it is not.0 / 5
TimingMissingA date is only a constraint if something makes it hard. A date with a reason gets planned around; a date without one gets negotiated away.No date, and no statement that there is no date. Silence here reads as “soon”, and “soon” is not plannable.0 / 6
Budget bandAnsweredA band is not a ceiling to be spent. It tells a vendor whether to propose what you described or a smaller first version of it.6 / 6
Decision processAnsweredWho signs, and how many people are in the room, predicts how long a decision takes far more reliably than the price does.6 / 6
What the vendor inheritsAnsweredDesigns, brand, a repository, hosting and a domain are either handed over or built. Which one is a real line on the quote.2 / 2
Total89 / 100

The brief

Both buttons work entirely in your browser. Nothing is uploaded, and no copy of this document exists anywhere but on this screen.

Project brief: Northgate Physiotherapy booking

Completeness 89 of 100 points. The last two sections are generated from what this document does not yet say.

Summary

Northgate Physiotherapy booking: Online booking and appointment recall for a three-site physiotherapy clinic, replacing a paper diary and a shared spreadsheet. This is a migration, which means the data currently in use has to arrive intact on the other side. The work is done today by hand: a shared spreadsheet per site plus a paper diary at each front desk. The launch scope is 4 items, with 3 explicitly deferred. It has to run on the web and an internal admin console. It integrates with Xero, Twilio for SMS and Google Calendar. It handles personal data and health or medical records, for users in Australia. Success is measured as: Ninety days after launch, at least half of all bookings arrive without a phone call, and the share of follow-up appointments never booked has halved. Both numbers come off the existing spreadsheet, so there is a baseline to compare against. The budget band is $18,000 to $45,000. The practice owner signs off, with 3 people in the decision.

Short enough for the body of a first email. Everything below is the attachment.

1. Context

This is a migration, which means the data currently in use has to arrive intact on the other side.

The work is done today by hand: a shared spreadsheet per site plus a paper diary at each front desk.

2. The problem

Reception spends most of the morning on the phone rebooking people, and roughly a fifth of follow-up appointments are never booked at all because nobody chases them. The three sites cannot see each other’s availability, so a patient who could be seen tomorrow at another site is told to wait a week.

3. What success looks like

Ninety days after launch, at least half of all bookings arrive without a phone call, and the share of follow-up appointments never booked has halved. Both numbers come off the existing spreadsheet, so there is a baseline to compare against.

4. Users and roles

  • Patient: book, reschedule and cancel their own appointments
  • Receptionist: book on behalf of anyone, at any site
  • Clinician: see and edit their own diary, mark outcomes
  • Practice owner: see everything across all three sites, plus reporting

5. In scope for launch

  • Online booking across all three sites
  • Clinician calendar with availability rules
  • Automated SMS reminders and recall
  • Reception dashboard for the day ahead
  • Responsive web app, built and released
  • Internal admin console, built and released
  • An integration that will write to Xero
  • An integration that will write to Twilio for SMS
  • An integration that will read from and write to Google Calendar

6. Explicitly out of scope

Anything in this section is understood to be excluded from the launch quote. It is written down so that no vendor has to guess where the line is.

  • Online payment at the time of booking (deferred, not part of the launch quote)
  • Patient-facing treatment notes (deferred, not part of the launch quote)
  • Insurer claim submission (deferred, not part of the launch quote)
  • iOS app (not required at launch)
  • Android app (not required at launch)
  • Public or partner API (not required at launch)

7. Third-party systems

  • Xero: the product will write to it.
  • Twilio for SMS: the product will write to it.
  • Google Calendar: the product will read from and write to it.

8. Data, privacy and compliance

Users are resident in Australia.

  • Personal data. Names, emails, addresses, anything tied to an identifiable person.
  • Health or medical records. The strictest category in most jurisdictions, and the slowest to review.

9. Platforms

  • Responsive web app. One codebase, every screen size. The cheapest surface to ship first.
  • Internal admin console. The screens your own staff use. Almost always underestimated.

10. Expected scale

Not answered. Give both numbers even if they are guesses, and say they are guesses. The gap between them is what decides the architecture.

11. Timing

Not answered. Either name a date and say what makes it hard, or write down that there is no date. Silence reads as “soon”.

12. Budget

$18,000 to $45,000. This is a band, not a target to be spent, and it is stated so that a vendor can propose the right size of first version rather than the largest one this brief will carry.

13. Decision process

  • Signs off: The practice owner.
  • 3 people are in the decision.

14. What the vendor inherits

  • Brand and typography. Logo, colours, type. Enough that nobody has to invent a look.
  • A domain. Registered, and with DNS you control.

15. Assumptions a vendor has to make

Generated from what this brief does not yet say. Every line here is a decision somebody else makes if it stays as it is, and they will make it in the direction that suits them.

  • That the audience is small enough that a single application server and one database are sufficient for the first year.
  • That there is no fixed date, so the schedule is the vendor’s to propose and the first version they propose will suit them.

16. Open questions

The questions a competent vendor will send back before quoting. Answering them in advance is the difference between a quote next week and a quote after two more meetings.

  • Does the old system have to keep running during the move, and for how long do both have to agree?
  • Of the 4 must-haves, which one would you cut if the date could not move?
  • Xero: which account, which plan, and who owns the credentials?
  • Twilio for SMS: which account, which plan, and who owns the credentials?
  • Google Calendar: which account, which plan, and who owns the credentials?
  • Which jurisdiction’s health data rules apply, and is there already a named compliance owner on your side?
  • How many people use this in month one, and how many in month twelve?
  • Who on your side is available every week to answer questions and review what has been built?

This is a brief, not an estimate, and a brief cannot make a bad idea quotable. It was assembled by deterministic templating in the browser, with no model call, so the same answers always produce this same document. Nothing in it was sent anywhere.

Built with the free project brief generator at edgebrainstudios.com/tools/project-brief-generator

What this cannot do

It cannot price anything

A brief is the input to an estimate, not an estimate. If you want a number, take the finished document to our MVP cost estimator and set its inputs from what you just wrote down. And a brief cannot make a bad idea quotable: a well-scoped document describing something nobody wants is a well-scoped document.

It cannot read your words

The completeness score counts whether a section has an answer, not whether the answer is any good. Five features called “dashboard”, “reporting” and “analytics” score exactly the same as five specific ones. That is a deliberate limit: a tool that judged your prose would need a model, and a model would make the output different every time you pressed the button.

The weights are ours

Thirteen sections, weighted by how far a quote moves when each one is absent. That ordering comes from what we have watched go wrong in scoping conversations, not from a published study, and a studio that builds different things would defend a different order. The whole table is on the page so you can disagree with a specific row.

How to read the output

The document is the smaller half of what this produces. The useful half is sections 14 and 15, and the completeness table that generated them. Read those first, then decide whether to send anything at all.

The score is not a grade

It counts answered sections against a published weight and shows the addition. A 74 is not a bad brief; it’s a brief with 26 points of decisions currently delegated to whoever reads it. That is sometimes the right call. If you genuinely have no view on scale, a vendor with an opinion about scale is more use than a number you invented so a bar would fill up. What you should never do is pad a section to raise the score, because the score is a proxy and the assumptions block is the real output.

Send the assumptions with the brief

This is the part people delete, and it’s the part that earns its place. When a vendor is told in writing which gaps exist and what will be assumed in their absence, one of two things happens. They accept the assumptions, in which case you now have those assumptions on the record and can hold a quote against them. Or they argue with one, which tells you they read the document and thought about the work. Silence in response to a stated assumption is itself information, and it’s the cheapest signal you will get before signing anything.

The out-of-scope list is the one that saves money

Buyers spend their effort on the must-have list because it feels like the substance. It is, but it is not where quotes diverge. Two vendors reading the same eight must-haves will land within a reasonable distance of each other. Two vendors reading eight must-haves with no exclusions will not, because one of them has quietly included a reporting module and the other has quietly excluded it, and neither of them told you. Section 5 exists so the silence has a place to be written down. Deferring something is not a failure of ambition, and a brief with nothing deferred reads as a brief nobody has finished thinking about.

Mistakes people make with a number like this

Treating a full brief as a finished decision. A complete document says what you want built. It says nothing about whether it should be. The completeness meter cannot see market, timing or whether three of these features already exist as a $40 a month product you could buy this afternoon.

Sending the same brief to five vendors and comparing only totals. That is the right thing to send and the wrong thing to compare. Compare which questions came back. A vendor who returns four specific questions from section 15 plus two you had not thought of has read it. A vendor who returns a total has priced a category.

Confusing a brief with a specification. A brief says what has to be true. A specification says how. Writing the second one before you have chosen a team means paying twice, once to write it and once for the team to disagree with it. This tool deliberately stops at the first.

Treating the budget band as a ceiling to be spent. Naming a band does not mean a quote arrives at the top of it, and withholding one does not protect you. It costs you the two weeks a vendor spends proposing a size you were never going to buy. The argument for saying it out loud is the same one behind choosing a contract type before the work starts: cheap information early is worth more than optionality late.

Letting a low score stop you sending it. A brief at 48 with an honest assumptions block is more useful to a vendor than a brief at 92 where six sections were filled in to make the meter move. The point was never the number. It was knowing, before anyone quotes, exactly which parts of this you have not decided.

Keep reading

Building the thing this brief describes is our web development, mobile app and AI automation work. The rest of the free tools are at /tools.

Send it to us first.

Paste the brief into the contact form, gaps and all. We’ll answer the open questions in writing before anyone talks about a price, and you keep the document either way. Send it to four other studios at the same time. That’s what it’s for.

Send us the briefSee what we have built