← Back to blog
·9 min

How to properly brief a freelance developer: a practical guide

Jonathan Delhoux

Jonathan Delhoux

Fullstack Developer, Technical Partner for Web Agencies

Share →

How to properly brief a freelance developer: a practical guide

Why the brief matters more than the developer chosen

A good developer with a poor brief will deliver a poor site. An average developer with a solid brief will deliver something correct.

This is not an exaggeration. In seven years of freelance work, the projects that went sideways shared a single trait: the brief was vague, incomplete or nonexistent. The client had an idea in mind without putting it in writing. When the outcome did not match that unstated idea, tensions accumulated.

Writing a solid brief does not take three days. Thirty minutes is sufficient when the structure is known. This guide provides that structure.

Three brief formats to avoid

The "do as you feel" brief

"We trust you, go with what feels right."

The intention is well-meaning. In practice, the client's implicit vision and the developer's rarely overlap. Without clear direction, decisions are made blindly, back-and-forths accumulate, and the budget drifts from its initial target.

The "like Apple" brief

"I want a site comparable to Apple, Tesla or Airbnb."

These sites are remarkable. They also required several million euros and fifty-person teams over months. With a 3,000-euro budget, the attainable result is a clean and professional site, not a reproduction of the references cited. The client's prospects are not, in fact, expecting that level of production.

The fifty-page brief

The opposite extreme. An exhaustive document listing two hundred features, the majority of which will never be used. The main effect is the dilution of what is essential. The developer loses sight of priorities and the quote incorporates developments that serve no practical purpose.

The effective brief in eight sections

1. Your business in five lines maximum

Who you are, what you do, for whom. Not a ten-year vision, not brand storytelling, just the facts.

A working example:

"Event caterer in Toulouse. Cook from an Airstream (food truck) for weddings, seminars and private events. Clients: individuals (weddings) and companies (seminars). 80% of revenue generated through word of mouth."

In four lines, the developer grasps the business, the target and the main acquisition channel. That is enough to inform the design.

2. The website's goal in one sentence

Why this site is being created. One goal, not five.

Structuring goals:

  • "Generate quote requests through a contact form"
  • "Showcase a portfolio to reassure prospects already in phone contact"
  • "Sell online courses with card payment"
  • "Allow clients to book a time slot directly on the site"

A non-structuring goal: "Have an online presence". Too vague to drive any design decision.

3. The three to five priority pages or features

If the site could only keep three pages, which would they be? For most showcase sites, the answer is:

  1. Homepage: presentation and hook
  2. Services or offerings, with rates where relevant
  3. Contact: form and details

The rest (blog, gallery, testimonials, FAQ) is complementary. It can be listed while marking it as secondary. This split helps the developer break the quote into blocks.

4. The target audience in two or three sentences

Who will visit the site? What is their profile? What do they expect when arriving on the page?

"Couples aged 25 to 40 planning their wedding, and corporate event managers. Looking for an original caterer. Expect photos of previous events and the ability to request a quote quickly."

A few lines of this kind materially shape the approach to design and site architecture.

5. Two or three examples of sites you appreciate

Not to reproduce them, but to convey the visual universe aimed for. Specify for each link what you like:

  • "Clean, uncluttered look"
  • "Scroll animations are well executed"
  • "The way photos are showcased here matches what is needed"

Counter-examples are equally useful. Stating "this approach should be avoided" eliminates certain directions upfront.

6. The content already available

The developer needs to know what they will be working with:

  • Text: written, to be written, or to be delegated to a copywriter
  • Photos: professional, phone-taken, or to be produced with a photographer
  • Logo: existing, or to be created by a graphic designer
  • Brand guidelines: colours and typography already defined, or full discretion

A site without mastered content resembles a mockup whose images are left in low resolution. Content represents at least half of the final perceived result.

7. Budget, a topic to address explicitly

The topic most often avoided early in the conversation, yet indispensable to move forward.

An exact figure is not required, a range is sufficient:

  • "Between 1,500 and 3,000 euros"
  • "Five thousand euros all-in maximum"
  • "No specific idea" is also acceptable, the developer will guide you

Rationale: a 2,000-euro budget facing a proposal calibrated at 8,000 euros wastes both parties' time. Better to place the data on the table from the start.

8. The deadline, if any

Is there a real deadline tied to a concrete event?

Structuring deadlines:

  • "The site must be live for the trade show on May 15"
  • "New commercial offering launching in September"

False deadlines: "As soon as possible" provides no useful information. In the absence of a real date, it is preferable to say so. The developer will plan accordingly, limiting unnecessary tension.

What a good developer will do with the brief

A serious developer reads the brief and responds with:

  1. Questions, a sign that they seek to understand the need rather than simply produce a quote
  2. A technical proposal, with framework choice, rationale, number of pages and architecture
  3. A detailed quote, with cost items stated explicitly and separately
  4. A schedule, with clear milestones and intermediate delivery dates

A developer who asks no question and produces a quote two hours after receiving the brief should trigger caution. Either the brief was not read, or a standardised document has been sent.

Common client mistakes observed

Repeated direction changes. A brief is a mutual commitment. Adjustments along the way are normal. Changing the fundamental direction three times lengthens timelines and derails the budget. In one recent case, a client who changed the main colour four times saw the delivery postponed by three weeks.

Soliciting ten providers. Two or three quotes are sufficient for comparison. Beyond that, invested time becomes counter-productive and heterogeneous approaches prevent meaningful comparison.

Comparing on price alone. The cheapest quote is not necessarily the best choice, and neither is the most expensive. Criteria to consider include the portfolio, understanding of the need in exchanges, responsiveness and relational quality. The collaboration extends over several weeks.

Lack of framing on maintenance. The site does not stop existing on the day of delivery. An annual maintenance budget should be anticipated, or at least discussed from the brief, to avoid renegotiation six months later.

Ready-to-complete brief template

The template below is designed to be filled in within thirty minutes.

BUSINESS:
[Who you are, what you do, for whom]

WEBSITE GOAL:
[One clear sentence]

PRIORITY PAGES:
1. [Page]
2. [Page]
3. [Page]

TARGET AUDIENCE:
[Visitor profile and primary expectations]

APPRECIATED WEBSITES:
- [URL], what is appreciated: [...]
- [URL], what is appreciated: [...]

AVAILABLE CONTENT:
- Text: [yes / no / partially]
- Photos: [yes / no / to produce]
- Logo: [yes / no]

BUDGET:
[Range or "to be defined"]

DEADLINE:
[Date or "no constraint"]

NOTES:
[Any element not covered by the sections above]

Template completed? Send it through, detailed feedback will reach you within 48 hours.

/ Share this

Share →

Available for sub-contractingToulouse · RemoteVue · Nuxt · Laravel · NodeAvailable for sub-contractingToulouse · RemoteVue · Nuxt · Laravel · Node
JDW.

Fullstack Developer, Technical Partner for Web Agencies, Toulouse

Network

© 2026 Jonathan Delhoux – JDW Development. All rights reserved.

Legal notice·Privacy policy·

[ Cookies ] This site uses cookies for its operation and, with your consent, to measure its audience. See our Privacy policy.