A developer is not a mind reader. If you tell them "we want a modern website that sells," you will get something modern with a shopping cart — but probably not what you had in mind. Most web projects that end in blown budgets or mutual disappointment do not fail because of bad technology or incompetent developers. They fail because of a bad brief. And a good brief does not write itself in an hour — but that hour saves you months of problems.
Why a bad brief costs more than a good developer
A construction firm does not show up on site without blueprints. A structural engineer does not calculate load-bearing capacity without drawings. And yet plenty of companies walk into a developer's office saying they "want a website" and trust the rest will sort itself out.
The problem is fundamental: a developer sees the world in terms of features and technology. You see it in terms of customers and business. If these two perspectives do not align from day one, everyone is building a different thing — and you only find out when it is finished.
Late changes are expensive. In software development, fixing an error in the requirements costs one unit of effort. Fixing the same error in the finished product costs ten to a hundred units. In plain terms: adding a page to a brief rather than rebuilding a finished website is the difference between an hour of conversation and a week of work.
Practical tip: Before writing a single line of your brief, answer this one question: "How will I know the website succeeded?" If the answer is "it will look nice" or "it will be modern," you are not ready yet. If the answer is "within six months of launch, 30% of new inquiries will come through the website," you have a foundation.
What belongs in a technical brief
A good brief is not a novel or a wish list. It is a precise description of what needs to be built, for whom, and why. Here is the minimum it should contain:
Website goals. What should the website actually do? Generate inquiries? Sell products? Communicate the company's credibility? Each goal has different implications for design and technology. Write them in priority order — not every goal carries equal weight.
Target audience. Who will use the website? B2B or B2C? Technically minded users or general public? Mobile-first or primarily desktop? Language of the target audience — will the site be in one language, or does it need to be multilingual from the start?
Feature list. Not a wish list, but a structured overview. What is required for launch (MVP)? What is nice to have? What can wait? This prioritization prevents the situation where nothing ships because everything must be done at once.
Design references. Show three to five websites you like. More importantly, explain why — is it the color palette, the layout, the photography, or the way it guides the user toward an action? References without explanation are nearly useless.
Technical integrations. What needs to connect to the website? A CRM? Accounting software? A payment gateway? A mailing platform? A warehouse system? For each integration, find out whether it has an API and what its documentation looks like.
Content. Who will supply the copy, photos, and videos? By when? In what format? This is the most consistently underestimated part — projects sit waiting for months because the content was not planned, even when everything technical is complete.
Timeline and budget. A developer needs to know what they are working with. If you have a fixed deadline — a trade show, a campaign launch, the end of a season — say so upfront. If you have a budget ceiling, say that too. You will save yourself a circular conversation about scope.
The most common mistakes in briefs
Requirements that are too vague. "The website must be clear and fast." Yes — that is a baseline expectation for any website. But what does it mean for your specific project? Clear for whom? Fast according to which benchmark? Vague requirements produce vague results.
Missing the "why." A company wants a product comparison table. Why? Because customers choose between three variants and need to compare technical specs — or because a competitor has one and "we can't be left behind"? These two answers lead to completely different solutions.
Copying competitors without thinking. "We want what company X has." But company X has different customers, a different business model, and different technical infrastructure. You also do not know whether their solution actually works — perhaps it cost twice the budget and converts poorly.
Real-world example: A Prague-based office supplies distributor briefed a developer: "We want an e-shop like the big guys." The developer prepared a quote for the equivalent of 32,000 EUR. After a more detailed conversation, it emerged that the company sells to B2B clients, has 200 products, and primarily needs an inquiry form with the option to attach a price list as a PDF. The final solution cost 3,200 EUR and covers 100% of the actual business need. The entire difference came down to the brief.
How to describe features correctly
Developers will build exactly what you tell them. The problem is they will build it literally — not what you meant by it.
Vague description: "We want a contact form." Result: a form with three fields (name, email, message) and a Submit button.
Actual need: the customer selects an inquiry category (service / order / general), the form accepts a file attachment up to 5 MB, the sender receives a confirmation email, and the submission is automatically logged in the CRM with the responsible person assigned by category.
The best way to describe features precisely is through user stories. The format is simple: "As a [type of user] I want to [action] so that [goal]."
Examples:
- "As a customer, I want to filter products by category and price, so I can quickly find what I am looking for."
- "As a sales director, I want to see a summary of web inquiries from the past month, so I can evaluate campaign effectiveness."
- "As an administrator, I want to add and edit pages without involving a developer, so I am not dependent on an external supplier."
For each user story, expand further: what happens after the action? What happens if the action fails? Are there any exceptions or edge cases?
| Approach | Example | Outcome |
|---|---|---|
| Vague requirement | "We want user login" | Basic login with no access controls |
| User story | "As a customer I want to log in with email to see my order history" | Login + customer area with orders |
| Full specification | User story + password reset + login attempt limits + 2FA | A production-ready auth system |
What happens when you skip the brief
Scope creep. The project starts as a "simple company website" and three months later you are discussing a customer portal that nobody described but which is "obviously implied."
Every feature added after a project starts costs more than the same feature in the original brief. The reason is straightforward: the developer has to rework what is already done, adapt the architecture, and retest everything.
Real-world example: A Brno-based marketing agency briefed a website: one landing page for a single product, an inquiry form, copy to be provided by the agency. The project was scoped at six weeks. In week three came a request for a blog. In week four, for a multilingual version. In week five, for an interactive pricing calculator. None of these were in the brief. The project finished after four months at double the budget. The agency was unhappy. The developer was exhausted. All of it could have been avoided by scoping the project correctly from the start.
The other consequence of a missing brief is disappointment with the result. The developer did exactly what was asked — but it is not enough, because "surely it was obvious that's not what we meant." In project management, that sentence is the most expensive phrase there is.
How to refine the brief together with your developer
A good brief does not emerge in isolation. The best approach is iterative: you prepare a rough version, the developer comments on it, you refine.
Start with a structured workshop. Two to three hours with the key people on your side — not an email thread, but a live conversation. Walk through goals, target audience, main features, and priorities. The output should be a list of functional areas and their priority ranking.
Let the developer ask questions. A good developer or agency will ask uncomfortable questions: "What happens when a customer forgets their password?", "How do you handle returns?", "Who will manage the website after launch?" These questions are not obstruction — they are things that will hurt you in six months if you do not answer them now.
Define acceptance criteria. For each key feature, agree in advance on how you will know it is done correctly. "The contact form works" is too vague. "The form sends an email to info@company.com, saves a record to the CRM, and displays a thank-you message within three seconds" is specific.
Practical tip: Write the brief, then set it aside for two days and read it again. Every requirement where you are unsure what exactly the developer will build is a requirement that needs to be sharpened.
Summary: minimum content of a working brief
| Brief section | Why it matters |
|---|---|
| Website goals with measurable outcomes | Defines what project success looks like |
| Target audience | Drives UX decisions and content |
| Prioritized feature list | Prevents scope creep |
| Design references with commentary | Aligns visual expectations |
| Technical integrations | Surfaces hidden complexity early |
| Content plan (who, what, when) | Prevents the project from stalling |
| Timeline and budget range | Enables a realistic estimate |
| Acceptance criteria | Defines what "done" actually means |
At BASAD Studios, we help clients work through their brief before we start building anything — because we know that one hour of good briefing saves weeks of work. If you are planning a new website and want to avoid the mistakes described above, get in touch or check out our website development service.