How to write a project brief for a website, app or software (with a template)

A project brief is one page that explains the problem you want to fix, who will use the result, what's essential, what you already have and when you need it. You don't need any technical knowledge to write one. It's your business, explained so someone else can build something for it.

If you've never written one, there's a template below you can copy and fill in. It takes an afternoon and saves weeks of misunderstandings.

Why it's worth it, even for a small project

The brief helps you first. Writing it forces decisions you hadn't made yet: whether orders get entered by customers or by your staff, whether the site needs two languages, whether it has to work on a sales rep's phone out in the field.

Then it helps whoever quotes the project. With a clear brief, the proposal you get back answers your business, not a general idea of it. And if you're asking more than one developer, sending everyone the same brief is the easiest way to make the quotes comparable; I explain that in how to request a software quote.

The template, section by section

Paste these headings into a document and answer each one in two or three sentences:

• 1. Who we are. What your business does, where and for whom. Example: “We build custom furniture for families and architecture firms.”
• 2. The problem. What costs you time, sales or customers today. Write it the way you'd explain it to a friend.
• 3. Who will use it. Your customers, your team or both. On what device, and at what point in their day.
• 4. What it needs to do. Split into three lists: must-have, nice-to-have and later.
• 5. What you already have. Website, spreadsheets, social accounts, old software, photos, copy. What works and what doesn't.
• 6. References. Two or three sites or apps you like, even from other industries, and what you like about each.
• 7. Timeline. When you need it and why that date: a busy season, a trade show, a launch.
• 8. How you'll know it worked. For example: “we stop retyping orders” or “inquiries arrive with the measurements included.”
• 9. Who decides. Who approves progress and who sends the content.
• 10. Open questions. What you're still unsure about. This one is as useful as the rest.

Sorting must-haves from the rest

Section 4 is the hardest. Here's an example for a manufacturer that wants to sell better through its website:

If everything is a must-have, nothing is. The first column is what the project is useless without.

Three mistakes I see a lot

• Describing screens instead of problems. “A blue button top right” gets decided later. What matters is what the button is for.
• Forgetting who loads the content. A site with lots of products needs someone to add and maintain them. Think about who, and whether they'll have time; my website content checklist is a good place to start.
• Wanting everything in version one. Launching something small that works and adding to it later usually goes better. That's the idea behind what an MVP is, and it applies to websites and business software too.

If your project is a configurator or quote tool

Add a few things to the template: which options the customer can pick (sizes, colors, models, extras), which combinations aren't possible, and what they should get at the end, whether that's a spec sheet, a price or an inquiry for your sales team. I wrote more about that in adding a 3D configurator to your website.

And if you don't know where to start, send me whatever you have, even if it's messy. We'll sort it out together.

Frequently asked questions