Why these questions
Most briefs fail the same way. They describe a solution in detail and never say what problem it solves, or they list twenty features and never say which one matters. A developer reading that cannot tell you what it costs, only that it might cost anything, so you get either a padded quote or a long series of questions before anyone can start.
Four things fix that, and they are what this tool asks for.
- What exists now. Nothing, a spec, finished designs, a half-built app. The gap between an idea and a spec is real work, and whoever quotes you has to know which side of it you are on.
- What done means. One paragraph, written as an outcome rather than a feature list. "A manager can build next week's rota in under ten minutes" tells a developer far more than a list of screens.
- Constraints that are real. A deadline that actually matters, a stack you genuinely cannot leave, a platform you have to ship to. Constraints you invented to sound organised will cost you money.
- Budget. The part people leave out, and the part that wastes the most time. See the questions below.
Short is fine
The fields here are capped deliberately. A brief that answers those four things in half a page beats three pages that answer none of them, and if you cannot say what done means in a few sentences, that is worth discovering now rather than two months into paying someone.
The one thing worth writing at length is the problem you are trying to solve. Everything else can be a bullet.
What happens after you send it
Expect questions. A good developer reads a brief and comes back with the three things that are ambiguous, which is a sign they actually read it rather than a sign the brief was bad. Expect a range rather than a number, at least at first. And expect the honest ones to tell you when part of what you want is not worth building.
Send it to two or three people. Comparing three quotes against one written brief is the fastest way to learn what the work is really worth, and it is normal enough that you can say you are doing it.
Questions
Do I have to say my budget?
You do not, but leaving it out costs you. Developers read an unstated budget as either "this will be a long negotiation" or "they have no idea", and the good ones with a queue simply reply to the briefs that have a number. If you genuinely do not know, say what the work is worth to you instead: "this unblocks about 2,000 a month of revenue" is a useful sentence and invites a real conversation.
What if I do not know what I want yet?
Then say that, and describe the problem rather than the solution. "Our staff rota lives in a spreadsheet and it breaks every time someone swaps a shift" is a brief someone can respond to. Inventing technical requirements you do not understand is worse than admitting the gap.
Is a short brief bad?
No. A short brief that answers what it is, what done looks like, what the constraints are and what you can spend beats three pages that answer none of them. The fields here are capped on purpose: if you cannot say what done means in a few sentences, that is worth knowing before you start paying someone.
Should I send the same brief to several people?
Yes, and say that you are. It is normal, it is fair to everyone, and it saves the awkwardness later. Three quotes against one written brief is the fastest way to learn what the work is really worth.
Is my brief stored anywhere?
No. Everything you type stays in the address bar and in the page you are looking at. Nothing is written to a database, and nobody here reads it. The link is the brief, which also means anyone you send the link to can see all of it, so treat it like an email rather than a secret.
Longer read: How to hire a freelance developer without Upwork or Fiverr covers the whole process: shortlisting from shipped work, checking a person is real, and structuring the first job so it can fail cheaply.