A briefing is not a set of specifications
The most common mistake in projects: the briefing turns into a feature list. Forty pages of requirements, with each feature described individually, but not a word about why the project is happening in the first place or how you’ll measure, two years from now, whether it was worth it.
A statement of requirements describes a clear solution. A briefing describes a problem, a framework, and the conditions under which the work will be carried out. The difference is crucial, because if you already specify the solution, you’re purchasing implementation capacity—not consulting services. For a medium- to large-scale project, that’s a costly waste.
Rule of thumb: five to ten pages. Anything beyond that belongs in the appendices—sitemap, Analytics export, system architecture, corporate design manual, etc.
These eight points belong here
1 – Background and Objective
Why now? Is a hosting contract about to expire, is the CMS on its last legs, has the brand positioning changed, is a merger on the horizon, or is maintaining the content taking up too much time internally? The reason dictates the priority. A relaunch due to legacy technical issues is handled differently than one driven by a new brand strategy.
Write down in two or three sentences what you want to see changed in twelve months. If you can’t reach a consensus internally on this in two sentences, you’ve already identified the most important finding—and you should clarify this before the pitch, not after.
2 – How You Measure Success
List two to four criteria, ideally with baseline values. More inquiries through the website? Fewer support calls? Shorter time-to-publish for the editorial team? Better visibility for specific topics? Clearer positioning?
3 – Target Groups and Their Roles
It’s not about demographics, but about tasks. Who visits the site, what is their purpose, and what do they need to accomplish once they’re there? For large websites, there are often four to six very different groups—customers, job applicants, the media, partners, existing users, and internal staff.
Prioritize your target audiences. If all target audiences are equally important, the website will end up being a compromise, and no one will be happy.
4 – Content: Quantity, Condition, Responsibility
That's the thing that makes or breaks projects. Answer these three questions:
-
Quantity: How many pages are on today's website, and how many of them will remain after the relaunch?
-
Condition: Will the text be carried over, revised, or rewritten? How old is the visual content? Is there usable video footage? Or does everything need to be created from scratch?
-
Responsibility: Who provides the key messages—the line departments? Who writes the final copy—Marketing, an agency, or someone outside the company? And who makes the final decision in the event of a conflict?
“We create content in-house” or “AI does it these days” isn’t an answer—it’s a risk. If no one is specifically assigned to the task and no resources have been set aside, content becomes a schedule killer—because quality checks, tone, and management of content creation are always necessary. In large projects, this is the most common cause of delayed go-lives.
5 – Strategy: What's Settled and What's Still Up in the Air
Make it clear what is non-negotiable and what is open to discussion. Specifically:
-
Existing CMS—and whether you're locked into it or want to switch.
-
Systems that need to be integrated: CRM, ERP, PIM, newsletter, job portal, search, login/SSO.
-
IT or compliance requirements: hosting location, data protection, accessibility, security reviews, approval processes.
-
Multilingualism: Which languages? Who does the translating? Is everything identical in all languages?
What you not You need to decide on the front-end architecture. Whether headless is the right choice and how Composable and MACH To make it worthwhile for you, this is a consulting service—be sure to specify the parameters precisely and ask for an explanation of the architecture.
6 – Budget and Scope
This is the least popular point—and the most important one. Without a budget framework, you’ll receive quotes that vary by a factor of three—and you won’t be able to compare them because each agency has assumed a different scope of work.
One question is enough. Add two details that are often overlooked: Is content production—text, photography, video—included in the budget or billed separately? And what’s planned for operations after the go-live? Large websites aren’t projects that end; they’re systems that continue to evolve.
It’s also helpful to categorize tasks as “Must,” “Can,” or “Later.” This forces you to prioritize internally and protects the project from scope creep down the line.
7 – Decision-Making Processes
Name the people, not the departments. Who is the project lead on your side? Who makes decisions about design? Who makes decisions about technology? Is there a committee that meets only once every six weeks—and if so, when are the meetings?
For medium- to large-scale projects, the speed of decision-making is often the limiting factor. If an agency knows this in advance, it can time the process accordingly rather than working against it.
8 – Schedule with concrete milestones
Distinguish between preferred dates and firm deadlines. A trade show appearance, the end of a contract, an anniversary, an annual report—these are fixed dates. “As soon as possible” is not one of them.
And list the times when you're not available: summer vacation, year-end, peak season.
Four Factors Drive the Budget
If you understand where the money is going, you can make targeted adjustments rather than across-the-board cuts. There are essentially four drivers—and they can be influenced to varying degrees.
Design: From Simple to Complex
Design is not a constant, but a spectrum. At one end is a clean, systematic layout: a few principles, consistently applied, and a solid library of components. At the other end is a design where every page is unique, with its own visual language, custom animations, elaborate transitions, illustrations, or 3D elements.
Both approaches are valid. But they differ significantly in terms of effort—not only in the design itself, but also in implementation and testing. Custom behavior must work on every screen size, with long German words, in four languages, with screen readers, and with minimal animation.
For your briefing, it's enough to outline your expectations for the design: There are 3 categories
Simply put: For you, design is more of a "must-have"—it should be in line with your brand, professional, modern, and unobtrusive.
Creative: You can expect a variety of design options to choose from, the opportunity to actively participate in the design process, and a creative process that leads to a distinctive, one-of-a-kind solution.
Award-Winning: You have the highest standards when it comes to design. Together, we’ll draw inspiration from award-winning websites and create an elaborate, unique design with great attention to detail, subtle micro-interactions, and animations for the modules and features.
Number of Modules
More modules and more features are more expensive than fewer — there’s no getting around that. However, effort and cost don’t just scale with the number of modules. Another key factor is how much logic a module contains and how flexibly it can be used.
Here’s an example: A module that outputs an image and some text can be built and integrated quickly. A module that generates new image content via an LLM API based on a defined image style and provides text suggestions to go with it is something fundamentally different. The same applies to a teaser that reacts contextually to taxonomies, entities, and collections and displays different content depending on the context. In both cases, the module list shows “1 module”—but in terms of effort, they’re worlds apart.
Added to that is the flexibility of use. A module that works in exactly one place is cheaper than one that functions properly on every page type, in every language, and in every combination. The latter requires more planning, more validation, and more testing—but pays off over the website’s lifetime because it allows the editorial team to build new features independently, rather than opening a ticket for every variation.
There are therefore three factors that affect pricing:
Number — how many modules and features in total
Logical Depth — static vs. data-driven, rule-based, or AI-powered
Reusability — Case-by-case solution vs. freely combinable module
Individual Features
Search functions, indexed search functions, filter functions, map applications with geolocation, login areas, forms with interfaces to CRM or ERP systems, job or product portals, personalized content. These are small standalone products within the website—each with its own specific requirements for data models, interfaces, and quality assurance.
A practical tip: Specify in your briefing which modules are absolutely necessary at launch and which can be added in a second phase.
Project Duration and Team Composition
Time is a cost factor in its own right, regardless of scope. Every additional week of a project means coordination, status meetings, re-familiarization with the project, and re-negotiating details that had already been agreed upon. A project that drags on from six to ten months isn’t just completed later—it becomes more expensive, even with the same scope of functionality.
The biggest influence here doesn't lie with the agency, but with your team: It must be able to make decisions. Don’t make decisions quickly—but make them final. What really drives up project costs are feedback sessions with twelve unweighted opinions, policy debates that are reopened after approval, and decisions that are postponed until the next committee meeting in six weeks.
What helps is actually quite straightforward: one person per discipline with a clear mandate, a set feedback schedule, consolidated feedback instead of parallel individual feedback, and a clear rule about what can still be changed after approval. If you outline this in the briefing, you demonstrate professionalism—and you’ll receive more realistic timelines in return.
Content: Text, Images, Video, Migration
The most commonly underestimated item. Content is rarely “already there.” Make sure to clarify the following in your briefing:
-
Texts: Who writes them—in-house experts, your marketing team, or an external copywriting agency? Who edits them? Who writes UI copy, and who writes technical content? How many pages is a realistic goal, and what is the timeframe for producing them?
-
Images: Do you need a photo shoot, is the archive sufficient, or do you use stock images? Having your own visual style is a strong differentiator, but it requires production, planning, and image rights. Visual material that’s more than a few years old often looks out of place on a new website right away.
-
Video: The most expensive type of content—and the most resource-intensive to produce in terms of streaming, formats, subtitles, and accessibility.
-
Translations: Who does the translating, who does the editing, and is all of this content really necessary in every language?
-
Migration: Will existing content be transferred? Manually transferring 500 pages is completely different from a script-based migration—and the difference depends on how well-structured the legacy data is.
If you address these five points in the briefing, you'll already stand out from most other proposals. And you'll receive quotes that actually include this work, rather than having it added later as a supplement.
The Three Most Common Pitfalls
Don't specify a budget so that "the market can play out." The result is a range of offers that can't be compared, and a comparison that ultimately only takes price into account—not the substance behind it.
Postpone this content until later. Design and development can be planned. Content cannot, especially when it comes from people who are handling the relaunch on top of their day-to-day work. Set aside the necessary resources before the project begins.
Retroactive scope expansion without a release process. Additional requests are normal. It becomes a problem when no one has defined who approves them and from which budget they are paid. Cover this in the briefing in two sentences.
Conclusion
A good briefing for a medium- to large-scale website project is honest, prioritized, and streamlined. It outlines the rationale, success criteria, target audiences, content requirements, technical constraints, budget, decision-making processes, and realistic deadlines. It leaves the solution open—because that’s why you’re bringing in an agency.
And it identifies the four key factors that determine the budget: design depth, number of modules, project duration (including decision-making capacity), and content. If you consciously adjust these four factors, you won’t end up with a cheaper website—but you will have one where your money goes where it makes the biggest impact.
The side effect is the real benefit: As you write, you realize where there is still no internal consensus. This clarification happens either now, in five pages—or later, in the middle of the project, when it will be significantly more expensive.
