What a project brief should include (with a template)

The parts of a good brief

1. 1.The problem: what is going wrong or missing today?
2. 2.Who it is for: the people who will use it, and roughly how many.
3. 3.What success looks like: how you will know it worked.
4. 4.What exists now: current tools, spreadsheets, systems or a previous version.
5. 5.The must-haves: the few things the first release cannot do without.
6. 6.Constraints: deadlines, regulations, technology you must use or avoid.
7. 7.Budget range: even a rough range helps a studio propose something realistic.
8. 8.Who decides, and when you need to move.

A template you can copy

Paste this into an email or our project form and fill in what you know. It is fine to write "not sure yet" for any line.

Common mistakes to avoid

• Starting with the solution ("we need an app") instead of the problem
• Listing every feature you can think of, with no priorities
• Leaving out the budget range, which forces everyone to guess
• Describing the screens but not the people or the workflow
• Forgetting the systems the new product has to work with

What happens after you send it

When a brief reaches us, we read it and aim to reply within one business day, either with questions or with an honest view on whether we are the right fit. If it looks promising, we set up a short call to talk through scope, and then send a written proposal covering scope, approach and cost.

You do not need a perfect brief to start. A few honest paragraphs about the problem are enough for a first conversation.