Website or app project brief: a free template and what people forget

What is a website project brief? It's the document that says what your website or app has to do, who uses it, what's out of scope and how you'll decide it's finished. For a small business, one or two pages are enough. You write it so that you get quotes for the same thing and can compare them. The template is below, ready to copy.

Why not just use a public tender template?

Public bodies follow formal procurement procedures, and their documents are written for that. You don't have that constraint. A private business can talk freely to suppliers, ask questions and change its requirements between two quotes.

In our view, a 40-page template copied from a public institution wastes your time and scares off smaller suppliers. You only need the answers that change the price.

What should a website project brief include?

Copy the template, fill it in and delete what doesn't apply. Where you don't know the answer, write "not sure yet". That's more useful than a guess.

1. Goal and metric

• What problem the project solves:
• How we'll measure that it worked (for example: X quote requests a month, Y completed orders):

2. Users and roles

• Who uses the website or app:
• What roles exist (visitor, logged-in customer, administrator):

3. Features

• Must have:
• Nice to have, if the budget allows:
• Out of scope:

4. Content

• How many pages, in which languages:
• Who writes the text and who provides the images:
• What content moves over from the old site:

5. Integrations

• Which systems it connects to (CRM, invoicing, payments, shipping):
• Whether they have an API or documentation:

6. Admin after launch

• Who edits the content, and how often:
• What we need to be able to do ourselves, without a developer:

7. Legal requirements

• What personal data we collect, and why:
• Do we sell online to consumers (yes/no):
• Do we have customers in the EU (yes/no):
• Are we a microenterprise (yes/no):

8. Hosting and maintenance

• Who pays for and manages the domain and hosting:
• Which updates and backups are included after launch, and for how long:

9. Ownership

• Who owns the code, design and content after payment:
• Whose name the accounts are in (domain, hosting, analytics, app stores):

10. Timeline

• The launch date we'd like, and the reason for it:
• Who approves on our side, and how quickly they reply:

11. Acceptance criteria

• What we check at handover to consider the project finished:

12. Budget range

• The range we have in mind:

On budget, even a rough range beats leaving it blank. For the "must have" list, if the project is a new app, our article on MVPs will help you cut.

How do you write a good requirement?

Describe what the user has to be able to do, not the technology. If you ask for "PHP and MySQL" without a real reason, you rule out suppliers who could have solved the problem just as well. If you do have a reason, such as an existing system your team maintains, write it down. The platform itself can stay open for discussion: we compared the options in WordPress vs custom website.

A good requirement can be checked by someone who wasn't in the meetings:

If you also want AI assistants to be able to read and quote the site, add that as a requirement too. Our GEO guide explains what it involves.

Why does it matter what's out of scope?

Because that's where misunderstandings usually start. You assumed the text was included, the supplier assumed you'd provide it. Neither of you was wrong, but nobody wrote it down.

Spell it out, for example: "Out of scope: translation into German, the mobile app, migrating old orders, photography." Besides preventing arguments, this list makes quotes comparable. A quote that's 30% cheaper may leave out things the other one included.

The same goes for acceptance criteria. Without them, "done" means different things to each side. A few sentences are enough: "A test order goes from cart to invoice on phone and desktop. The administrator changes a price without help. Old addresses redirect."

Which legal requirements belong in the brief?

You don't need legal language, but the supplier has to know what applies, because that changes the work and the price. The rules below are EU rules, and whether they apply to you depends on where you are and who you sell to.

Accessibility. Since June 28, 2025, the European Accessibility Act (Directive (EU) 2019/882) has covered e-commerce services provided to consumers (Art. 2(2)(f)). There's an exemption: microenterprises providing services don't have to meet these requirements (Art. 4(5)). A microenterprise is a business with fewer than 10 employees and an annual turnover or balance sheet total of up to €2 million (Art. 3(23)). If you're outside the EU and sell to consumers there, ask a lawyer whether this applies to you. As a technical benchmark, you can ask for WCAG 2.2, level AA: for example, a contrast ratio of at least 4.5:1 for text.

Personal data. The GDPR applies if your business is established in the EU, or if you offer your site or app to people in the EU (Art. 3). In that case, if the supplier processes personal data on your behalf, for example by managing your customer database, the GDPR requires a contract setting out the subject matter and duration of the processing, its nature and purpose, the type of data and the categories of people concerned. At the end, the data is deleted or returned, at your choice (Regulation (EU) 2016/679, Art. 28(3)). The same regulation also requires data protection by design and by default (Art. 25) and security of processing (Art. 32).

Code ownership. This is where assumptions cost the most. Under EU rules, unless a contract says otherwise, the economic rights in a program created by an employee belong to the employer (Directive 2009/24/EC, Art. 2(3)). That rule covers employees, not a supplier you hire, so write down in the contract who owns the code after payment. If a lot is at stake, ask a lawyer.

What do you do with the quotes once you have them?

Send the same document to everyone and ask for an answer point by point. Put the quotes in a table, using the rows from the template. Where a quote doesn't answer something, ask.

A serious supplier will probably push back on a few points. That's a good sign: it means they read the document.

What does Navitech do with a project brief?

We write the brief together with you, and the work on it is included in the quote.

Our Website package starts at €1,000 excl. VAT, without hosting, domain or maintenance, and web and mobile apps start at €5,000 excl. VAT, with an MVP delivered in 2 months. We build new sites custom, with our own admin panel. You can see the projects we've delivered on our work page.

Frequently asked questions

How long should a website project brief be?

For a brochure site or a small store, one or two pages are enough. An app has more features to describe, but length isn't the goal: every line should help the supplier estimate or check something.

What's the difference between a brief and a requirements document?

For a small business, in practice, not much. "Brief" is more common in marketing and design, "requirements document" when there are detailed requirements and acceptance criteria. What matters is what's in the document, not what you call it.

Should I specify the technology?

Only if you have a reason: an existing system, a team that already knows a certain technology, or an integration that requires it. Otherwise, describe the result and let suppliers propose a solution.

Should I share my budget?

We recommend a range. Without one, you get quotes for very different projects: one proposes a theme, another a build from scratch.

Can I use the same template for a mobile app?

Yes. Add the platforms (iOS, Android, web), who owns the app store accounts and what goes into the first version.

Have you written your brief?

Send it to us, or tell us what you have so far: what you want to build, who it's for and by when. We'll reply with a clear quote, point by point.

Request a quote →

Sources

1. Directive (EU) 2019/882 (European Accessibility Act), Art. 2, 3 and 4: https://eur-lex.europa.eu/eli/dir/2019/882/oj
2. W3C, Web Content Accessibility Guidelines (WCAG) 2.2 (December 12, 2024): https://www.w3.org/TR/WCAG22/
3. Regulation (EU) 2016/679 (GDPR), Art. 3, 25, 28 and 32: https://eur-lex.europa.eu/eli/reg/2016/679/oj
4. Directive 2009/24/EC on the legal protection of computer programs, Art. 2(3): https://eur-lex.europa.eu/eli/dir/2009/24/oj
5. Navitech, packages and prices: https://navitech.systems/en