The short answer
Prepare short answers to seven questions: what you want to build, who will use it, how it is done today, what a good result looks like, examples you like, when you need it and your budget range, and who decides. A page of notes is enough.
The clearer your answers, the more accurate the quote, and the fewer surprises later.
What do you want to build, in one or two sentences?
Say what it is and what it should do. "A booking website for my clinic" is a good start.
Avoid describing the technology. You do not need to say whether it is an app or a website. Describe the problem and who it is for, and let the software house suggest the right form.
Who will use it?
Customers, your team or both? Roughly how many, and on what devices? If most will use a phone, say so.
Also mention anything that affects how people use it: whether they are comfortable with technology, whether they use it in a place with a weak connection, and which languages they read.
How is it done today?
Describe the current process: spreadsheets, paper, messages. It tells us what to replace and what to keep.
Even a rough list of steps helps. Say who does each step, how long it takes and where mistakes happen.
What would a good result look like?
Fewer phone calls, faster reports, more enquiries. One clear result is easier to design for than a long list of features.
If you can, say how you would notice it worked, for example "we answer the same question by phone ten times a day, and we would like that to be rare".
Do you have examples?
Links to sites or apps you like, a logo, existing documents. Examples save many rounds of explaining.
Also say what you do not like in examples you have seen. It is as useful as what you do like.
When do you need it, and what is your budget range?
A deadline and a rough range let a team suggest a realistic first version. If you are not sure, say so.
A budget range is not a trap. It helps the team decide what to include first and what to leave for a later phase, so you get the most useful version for what you can spend.
Who decides?
Name the person who approves the work. Projects move faster when there is one clear decision-maker.
If several people need to agree, say who, and agree among yourselves before you start. Changing direction halfway is a common reason for projects to run late.
A one-page brief you can copy
- What we want to build, in one or two sentences.
- Who will use it, how many, on which devices.
- How we do it today, and what goes wrong.
- What a good result looks like.
- Examples we like, and why.
- When we need it, and our budget range.
- Who decides.
What to expect after you send it
A good software house will reply with questions, then send a written scope, timeline and price. It should tell you what is included and what is not, and who owns the result at the end. If anything is unclear, ask before you agree.
Our guide on how to choose a software house lists the questions to ask when you compare proposals.
Ready to start?
Our short conversation asks exactly these questions and turns your answers into a brief we can start from.