Most disagreements in website projects come not from bad faith but from a sentence nobody wrote down. The business says "we're getting a website", the supplier hears "we're building a website", both use the same word, and six weeks later what emerges is what neither of them meant. Who was going to write the copy, how many rounds of revisions were there, what did "live" mean — if none of this was discussed, the answer gets hunted for in the middle of the work, in a tense meeting.
The brief is the document that closes that gap. Most of what you find under this heading in Turkish-language sources is either pages selling copywriting services or articles on how to evaluate a proposal. Both are useful, but both leave the same gap: to be able to compare proposals, you first have to write a request that can be compared, and the party that writes that request is the business.
What follows treats the brief not as a wish list but as a draft of the scope: which fields should be filled in, how to write what is out of scope, how to define a revision round and what a handover criterion looks like.
A brief is not a wish list, it is a draft of the scope
Most briefs are written as a list of wishes: make it modern, make it fast, don't make it look like our competitors. None of these sentences produces scope, because none of them can be ticked off as "done" or "not done".
A brief that works is built from sentences that can eventually turn into a contract. The test is this: every item in the brief should be a statement that both sides can call "complete" in the same way when the project ends. "A modern design" does not pass that test; "three templates will be designed: home page, service page and article page" does.
That does not mean the brief has to be a technical document. The business side may have no technical knowledge, and it does not need any. What is needed is for the wishes to be made countable and observable. How many pages, which languages, which features, who writes the copy, what is expected to be ready by which date.
Eight fields every brief must contain
When the following eight fields are filled in, the chance that the proposals coming back can be compared rises noticeably.
Purpose of the work. Why the site is being built: new customer demand, informing existing customers, recruitment, or all of them. The purpose sets the priority of the pages.
Audience. Who will come to the site, and with what question. If there are two different audiences, both get written down.
Page list. A first list, even if it is not final. Without a list, the party writing the proposal uses its own assumption and two proposals get priced on different numbers of pages.
Content status. Does copy exist, does it partly exist, or does none exist. Are the images and logo files to hand. This field is the line item that affects the project's duration most.
Features. Items such as forms, multiple languages, membership, search, booking, maps and live chat are written out one by one. The phrase "a standard website" means two different things to the two sides.
Technical constraints. The existing domain, the existing hosting, the company email setup, the brand guidelines and any tools that must be used.
Timeline expectation. If there is a fixed date, the reason gets written down too: a trade fair, a launch or a contract renewal. When the reason is written, the supplier can say which line item can be shortened.
Decision process. Who approves, how many people approve, how quickly feedback comes back. This field is almost never found in briefs, and it is the line item that determines the duration most.
Writing down what is out of scope: the two most expensive sentences
Most briefs say what will be done and do not say what will not be done. Yet disagreements almost always come out of that second list.
Writing down what is out of scope is not about protecting the supplier; it protects both sides. The business finds out that a job it assumed was included is not included at the start of the project rather than in the middle; the supplier is not forced to meet an expectation nobody wrote down.
In business website projects the items that spark the most arguments are these: copywriting, photography, logo and brand identity work, entering product or service data, migrating content from the existing site, translating the multilingual version, post-launch maintenance, and training. For each of them a single line in the brief is enough: included, not included, or priced separately.
The second expensive sentence is the phrase "and similar". Those two words tacked onto the end of a scope list make the whole list vague. The list should be closed; if things will be added later, the method for doing so should be written down.
Who owns the content: responsibility for copy, images and data
At the top of the reasons website projects run late is copy that is still being waited on. The design is finished, the development is finished, the page sits ready for launch with placeholder text, and the project hangs in limbo for weeks.
Splitting responsibility into three items in the brief makes that risk visible.
Copy. There are three options: the business writes it, the supplier writes it, or the business provides a draft and the supplier edits it. Each of the three has a different cost and duration. If the supplier will write, what they will base it on should also be specified — interviews, existing documents, or the sales deck.
Images. Are there real photos of the premises, the team and the work, will there be a shoot, or will it proceed with stock images. These three outcomes are not interchangeable; a business page built on stock images does not show the business's own reality.
Data. Service lists, team details, references, certifications, contact details and, if there are any, price tables. Who holds this data and who is responsible for its accuracy should be written down; in regulated sectors in particular, the final check rests with the business.
Writing a single named person for each item gives a far better result than the phrase "the team will handle it".
How to define a revision round, and why "unlimited revisions" is bad
The phrase "unlimited revisions" looks at first as if it works in the business's favour. In practice it turns out badly for both sides, because it makes the scope vague, and vague scope shows up in one of two places: the price or the quality of the work.
A healthy definition contains these three parts.
What a round is. A revision round is a single cycle in which feedback is delivered all together. Five separate requests arriving in five separate emails are not five rounds but parts of one round — but that is only so if it was written down.
How many rounds there are. This is specified separately for the design stage and the development stage. Two rounds are a reasonable starting point for most projects.
What counts as outside a round. Going back on a decision that was already approved is not a revision but a change of scope. For example, adding a new page after the page plan has been approved is not a revision round; it is assessed separately.
Once this definition is written, the quality of feedback goes up as well: the parties start collecting their feedback and giving it in one go, and scattered, contradictory requests become fewer.
Handover criteria: what "live" actually means
The sentence that ends the project is not "the site is live"; it is "it passed acceptance testing". Acceptance testing is a checklist written into the brief in advance, one that both sides can read the same way.
For business website projects the core of that list usually includes the following: every page opens from its correct address, the layout does not break on mobile or desktop, the forms were tested with a real submission and the email arrived, the page content is visible in the source, no search engine block is left in place, the sitemap and the robots file are correct, the analytics setup works, and the admin access has been handed over in the business's name.
The last item matters in particular and is an inseparable part of the handover: whose name the domain, the hosting, the admin panel and the measurement tools are registered in should be settled at the moment of handover. We set out the full list of these items and the order of the transfer in detail in our digital asset ownership and handover checklist.
We explained why the technical acceptance criteria are made up of these items, and how each one is verified, in our guide to website infrastructure for small businesses.
The line item that really sets the timeline: the approval cycle
The duration discussed at the proposal stage is usually production time: how many weeks for design, how many weeks for development. The item that sets the real calendar, though, is most often not that but the approval cycle.
A simple observation: two projects of the same scope, one run with a single decision-maker and feedback returned in two days, the other with a five-person approval committee and feedback returned in two weeks, finish in noticeably different amounts of time. The production time is the same; the difference is in the waiting.
That is why writing the decision process into the brief is not a formality. What needs writing down: who gives final approval, who the interim approvals go through, what turnaround time is committed for feedback, and whether there are holidays or busy periods.
In the same way, a proposal that promises a fixed delivery date should be read carefully: if the content is coming from the business and the approval time is uncertain, the supplier cannot hold that date on its own.
Reading the price gap: why two proposals for the same job differ
The difference between two proposals is most often not the same job priced differently but different jobs described under the same name. The way to read the difference is to look not at the total but at the scope lines.
The typical items that create the difference are these: the number of templates (three templates and ten templates are not the same job), whether copywriting is included, a multilingual version, the split between setting up on a ready-made theme and custom development, the length of post-handover maintenance, training and documentation, and the scope of the measurement setup.
The pricing model widens the gap as well. A fixed price is predictable for both sides when the scope is clear. Staged payment is fairer in projects where the scope becomes clear stage by stage. Time-based work is used for jobs whose scope cannot be written at the start, but in that case a cap and the reporting format should be written down.
The only thing that makes comparison possible is the proposals answering the same brief. Two proposals given in response to different briefs cannot be compared; they can be put side by side, and that is all. We gathered a nine-question set on how to probe a supplier's way of working and its reporting discipline in our article on auditing your current agency; the same questions work when evaluating a new supplier too. How fee models work, and the incentives each model creates, we took up separately in our article on agency fee models.
Where maintenance, updates and support sit in the handover
After the handover, a site does not stay upright on its own. Software updates, certificate renewals, backups, adding content and small fixes are ongoing work, and the brief should state whose responsibility each of them is.
Three models are common. Your own team runs it: in that case you need to ask for training and documentation at handover. The supplier runs it under a maintenance agreement: what the scope is — how many hours, which jobs are included, the emergency response time — gets written down. A mixed model: content entry sits with the business, technical maintenance with the supplier.
Whichever model is chosen, one sentence should be made clear in the brief: from the handover date onwards, which jobs fall under free support, and for how long.
Brief template
The list below can be copied and filled in. Every line should be answered in a single sentence; a line that cannot be answered is the riskiest point in the project.
- Purpose of the site and its measure of success
- Target audience and the questions they arrive with
- Page list and the question each page answers
- Languages and which pages will be translated
- Feature list (form, search, booking, membership, etc.)
- Copy, image and data responsibilities (name by name)
- Out-of-scope items
- Number of revision rounds and the definition of a round
- Acceptance test items
- Timeline and approval process
- Pricing model and payment stages
- List of access rights to be handed over at delivery
- Scope of post-handover maintenance and support
If you would like to see how we write scope, revision and handover criteria, you can take a look at our corporate website service page, and to work out your own brief together, you can reach us.
Frequently Asked Questions
Should we write the brief ourselves, or should the agency produce it?
The healthiest approach is for the two to take turns. The business writes the first draft — setting out the purpose, the audience, the page ideas, the content status and the timeline expectation in its own words. The supplier reads that draft and sends back the missing and contradictory points as questions, and the scope becomes clear in that round. The drawback of leaving the first draft entirely to the supplier is this: the brief fills up with the proposing party's assumptions, and comparing the proposals received against that brief becomes harder. The business does not need technical knowledge; what it needs is to know its own business.
How much detail is too much detail?
The test is this: a brief should state what needs to be met, not how the result will look. Specifying in detail which pages there will be, which features are needed and who will write what is useful. By contrast, fixing the button colour, the typeface and the order of the sections in the brief stops the supplier from producing a solution and usually leads to a worse result. A practical line: if an item can be ticked off as "done or not", it goes into the brief; if it depends on the question "do we like it", it is left to the design stage.
Fixed price or staged payment?
It depends on how clear the scope is. If the page list, the features and the content responsibilities can be written down at the start, a fixed price is predictable for both sides. If the scope will only become clear after discovery work, it is more realistic to price the discovery as a separate stage first and have the rest of the work quoted on the basis of that output. Whichever model is chosen, tying payment to stages and to concrete delivered outputs — design approval, completion of development, acceptance testing — reduces uncertainty.
What happens if we want changes after the handover?
This is a question that should be answered in the brief in advance. Two categories need separating: bug fixes and new requests. Failing to meet a criterion defined in the acceptance test is a bug, and fixing it is part of the handover. A new request that falls outside the approved scope, on the other hand, is new work and is assessed separately. Having this distinction written into the brief settles, from the start, the argument that strains the post-handover period most. The length of the free support period should also be stated in the same section.
How many agencies should we send the same brief to?
Between three and five is an adequate range for most projects. Fewer leaves no room for comparison; more pushes the evaluation workload to a point the business cannot carry, and giving each proposal a fair hearing becomes harder. What matters is consistency more than the number: the same brief should go to all of them, the same questions should be asked, and the proposals should be compared in the same columns. Proposals given in response to different briefs, or to different verbal explanations, are not comparable.