The most common reason a website project goes wrong isn't the developer. It's the brief — or the absence of one.
A developer who starts work without a clear brief will make assumptions. Some will be right. Most won't. The result is a site that looks acceptable but doesn't do what the business actually needed it to do, and a client who feels like the developer "missed the point." Both parties are frustrated. The project costs more than it should have.
A good brief eliminates most of this before a line of code is written.
What the Brief Needs to Cover
What the Website Needs to Achieve
This is the most important question, and it's the one most clients skip. Don't describe what you want the website to look like — describe what it needs to accomplish. If you're not sure what that looks like, what makes a good business website is a useful starting point before you write a single line of your brief.
"Generate leads from B2B clients in the manufacturing sector." "Allow customers to place orders online and track delivery." "Establish enough credibility that prospects who find us on Google trust us before they call." These are jobs a website can be built around.
"Make us look professional" is not a job. It's a vague aesthetic preference that will produce a vague result.
Who the Target Audience Is
A website for purchasing managers at Indonesian manufacturing companies looks and reads very differently from one aimed at consumers buying fashion products. If you can describe your target customer — industry, role, how they find vendors, how they make decisions — the developer and any copywriter involved can make much better choices about structure, tone, and emphasis.
"Everyone" is not an audience. The more specific you are, the better the result.
What Action You Want Visitors to Take
Every page should lead somewhere. What's the primary action? Fill a contact form? Call a number? Book a meeting? Download a document?
Pick one primary action per page. When a client says "I want them to be able to do everything," the result is a homepage with five equal-weight calls to action and visitors who do none of them. Forced choice, even on a website, leads to inaction.
Examples of Websites You Like and Why
"I want something like Tokopedia's website" tells a developer almost nothing useful. "I like the way Tokopedia's category pages are organized — the filtering is on the left, products are easy to compare, and the price is always visible without clicking through" tells them quite a lot.
Send 3-5 examples. For each one, say specifically what you like. The visual style? The way services are described? The checkout flow? The navigation structure? The clearer you are, the less the developer has to guess at your preferences.
Competitor Sites
Which competitors have sites you think are doing well, and what specifically is working? Which have sites that clearly aren't? This helps the developer understand the landscape your business operates in and avoid building something that feels generic for your industry — or that accidentally mirrors a competitor's structure too closely.
Your Existing Brand Assets
Do you have a logo? Brand colours? A defined font set? A style guide?
If yes, provide them. If no, say so — the developer needs to know whether branding is in scope or assumed to already exist. If you have brand guidelines and don't share them, you'll end up with a website in the wrong colours that needs revision. If you don't have them and don't mention it, the developer will invent something that may not align with how you present the business elsewhere.
Content: What You Have and What Needs Creating
Content is the thing that always delays projects. A developer can build a website structure in a few weeks. The project then sits for months waiting for the client to write copy, provide photos, or source case studies.
Before you brief the developer, be clear about which of these you already have and which you'll need help creating:
- Homepage copy
- Service or product descriptions
- About page content
- Team photos or brand photography
- Testimonials and case studies
- Supporting articles or resources
If you need copywriting support, say so upfront. It adds cost and time, but building it into the project plan is far better than discovering the gap three weeks before launch.
Budget Range and Timeline
Many clients are reluctant to share budget. The reasoning is usually "I don't want to anchor high and get overcharged." This reasoning produces the opposite of the intended effect.
Without a budget, a developer has to scope for an unknown. They'll either guess high — and you'll think they're expensive — or guess low and deliver something that doesn't cover your real needs. When you share a budget range, the developer can scope appropriately: tell you what's achievable in that range, what you'd need to add to do more, and what could be cut to stay within it. You get a better proposal.
Timeline matters too. "I need this live before a trade show in eight weeks" changes everything about how the project gets resourced and what scope is realistic.
The Red Flag
A developer who takes your brief, nods, and sends a quote without asking any follow-up questions is a red flag.
Good developers ask questions because they're trying to understand the problem before proposing a solution. They'll ask about your users, your current site's weaknesses, your integration requirements, your plan for content after launch. If a developer never asks you anything, they're either deeply experienced in your exact niche — possible but uncommon — or they're building something generic without engaging with your specific situation.
The brief starts the conversation. The follow-up questions are where the project actually gets defined.
The Brief Is a Two-Way Document
A brief isn't just something you hand to a developer and walk away from. A good developer will use it as a starting point for a structured conversation. They might push back on scope, suggest a different approach to the primary call to action, or point out that two of your goals are in tension with each other.
That conversation is valuable. It only happens if your brief was specific enough to provoke it.
CERIS starts every website project with a structured discovery process — a vague brief produces a website that requires expensive correction later. See our web development service or get in touch and we'll work through this together before any design or development begins.
