How to write a brief for a developer: template and mistakes to avoid

The quality of a project begins with how it is told. A clear brief leads to a precise estimate, fewer misunderstandings and fewer revisions. A vague brief leads to quotes that cannot be compared, surprises along the way and a result different from the one imagined.

The good news: writing a good brief is not difficult, and does not require technical skills. You just need to answer a few questions, honestly. In this guide you will find which ones, with a template to copy.

What a brief is for

A brief serves three purposes.

• For you, to clarify your ideas: writing forces you to decide what you really want.
• For the developer, to understand the problem and propose the right solution, with a realistic estimate.
• For the collaboration, as a common reference when doubts arise about what was agreed.

The ten pieces of information you need

1. Who you are and what you do

One line about the business: sector, size, who you sell to. It helps the developer understand the context.

2. What the problem or goal is

The most important part. Not "I want a website", but "I want people searching for X to contact me" or "I want to stop entering orders by hand". A measurable goal is better still.

3. Who it is for

Who will use the site or app: customers, collaborators, a small group. How many there are, how comfortable with technology.

4. What it must do (the features)

List the indispensable features and, separately, the "nice to have" ones. Describe them as actions ("the user can book a time slot"), not as technologies.

5. What already exists

Current site, management systems, spreadsheets, accounts, brand, design. Even what does not work well is useful to know.

6. What it must talk to

Other programs or services to connect: management system, CRM, payments, couriers, invoicing, calendars.

7. Available materials

Design (even just sketches), copy, images, logos, access. What is ready and what has yet to be produced.

8. Timing and deadlines

A desired date and why (a launch, a campaign, an event). If there is a hard deadline, say so straight away.

9. Budget

Even an indicative range. It guides choices and allows suitable proposals.

10. Constraints and preferences

Mandatory technologies, security or privacy requirements, languages, accessibility, hosting already chosen.

A template to copy

You can use this outline, filling it in with your own words.

• Who I am: …
• Project goal: …
• Who it is for: …
• Indispensable features: …
• Desirable features: …
• What already exists: …
• Links with other systems: …
• Available materials: …
• Timing and deadlines: …
• Indicative budget: …
• Constraints: …
• Examples I like (and what I like about them): …
• Who decides and who approves: …

A few lines per item are enough.

The most common mistakes

• Describing the solution instead of the problem. "I want an app" does not say what you need to achieve. There is often a better route.
• A brief that is too vague. "A modern, beautiful site" does not allow anything to be estimated.
• Too many things at once. Listing everything as indispensable inflates time and costs.
• Hiding the budget. Then proposals arrive far from what you can afford.
• Forgetting the links with other systems, which weigh a lot on the work.
• Changing your mind along the way without renegotiating time and costs.
• Too many people deciding. You need a contact and a person who approves.
• Not saying what already exists, and finding out later about missing access or technical constraints.

How to judge the reply

When proposals arrive, look first at how they are written, then at how much they cost.

• Do they ask questions? Whoever understands the problem asks them.
• Do they restate the goal to check they have understood?
• Do they say what is included and what is not?
• Do they give timing by phase, not just a final date?
• Do they put everything in writing, with the steps and conditions?
• Do they explain how they work: previews, revisions, communication?
• Do they clarify ownership of code and access, and what happens after delivery?

For the criteria for choosing who develops, read How to choose a freelance developer for your agency, and to understand what drives price How much does a website cost in 2026.

If you do not yet have clear ideas

That is perfectly fine. In that case a brief of a few lines ("I have this problem, I would like to understand what can be done") is already a good start, followed by a chat. A good developer helps you turn the problem into a project, without pushing you towards the biggest solution.

An example of a short brief

To give the idea, here is how a version of a few lines might sound, invented for illustration.

"We are a professional practice with five people. Today clients write to us by email and we fix appointments by phone. We would like a site where clients can book a meeting by choosing a free time slot, with bookings arriving in our calendar. We need two languages. We already have a logo and colours, but not the design. We would like to start within two months. Indicative budget to be defined together after a chat."

It is not perfect, but it contains goal, users, main feature, a link with another tool, languages, materials and timing. The rest is clarified by talking.

Why entrust it to me

I have been programming since 1999, with more than 300 projects delivered and about 30 agencies as an external developer. If you send me a brief, even a short one, I reply with a first assessment and, if needed, a few questions to bring it into focus, then a written, free estimate, fixed-price or daily-rate. I develop in stages, with online previews every week, and leave clean, tested, documented code. I work from Rome and remotely.

If you have a project to tell me about, write to me: a chat of about 20 minutes, no strings attached, helps us bring the brief into focus together. The service is in Custom software development and programming.