What a Website Brief Should Contain Before You Ask for Quotes

"Need a website, something modern, please quote"

That's the entire brief behind a large share of Malaysian SME website enquiries — sent over WhatsApp, often to three or four vendors at once, in the hope that whoever comes back with the lowest number wins. It rarely works out that way, because a one-line brief doesn't give any two vendors the same project to price. One reads "modern" as a five-page brochure site. Another reads it as a full e-commerce build with a customer portal. Both quote honestly against what they understood — and the client ends up comparing numbers that don't describe the same thing.

A brief isn't paperwork you write to satisfy a vendor's intake form. It's the only way multiple quotes can be compared against each other at all, and the only way any single quote can be checked against what actually gets delivered later. This is what a workable brief needs to contain, and why each part earns its place.

The business outcome, not just the deliverable

Start with what should change in the business because this website exists — not "we need a website" but "we need to stop losing enquiries to a competitor whose site ranks higher" or "we need customers to book online instead of calling, because phone bookings are eating staff time." A vendor pricing a site with no stated outcome will default to pricing pages and features. A vendor who knows the outcome can flag, before any deposit is paid, whether the plan actually gets there — for example, that a five-page brochure site alone won't reduce phone bookings if there's no booking form on it.

This doesn't need to be a formal goals document. Two or three honest sentences about what's not working today and what should be different in six months is enough to change how a vendor prices and designs around it.

Who the site actually needs to work for

Audience isn't a marketing exercise here — it's practical input that affects real build decisions. A site aimed at older B2B buyers filling in an enquiry form on a desktop browser needs different priorities from one aimed at younger consumers browsing on a phone and expecting to check out in three taps. If the site needs to work in more than one language for different audience segments, or needs a business-facing area (a dealer portal, a wholesale price list) alongside the public-facing one, that's an audience distinction that changes scope, not a footnote.

The pages and functionality you actually need

List pages by name and purpose, not by count — "a Services page listing our four service lines with a short description and starting price for each" is answerable; "a services page" is not. Do the same for functionality: a contact form is a small thing to build; a contact form that routes by service type to different staff inboxes, or a booking system that checks real-time availability, is a materially different piece of work that needs to be named as such, not discovered mid-project. If you already know you'll need a payment gateway, a booking calendar, a multi-location store locator, or a customer login area, say so up front — these are exactly the items that separate genuinely comparable quotes from ones that only look comparable on the cover page.

Whether your content actually exists yet

This is the input clients most often assume is the vendor's problem and vendors most often assume is the client's. Before asking for quotes, know roughly how much of the site's copy, product information, and photography already exists in a usable form, versus how much still needs to be written, sourced, or licensed — and who is doing that work. A vendor quoting "website build" with no stated content plan is quietly assuming one of two very different scenarios: that you'll deliver finished copy on schedule, or that writing it is included in their number. Only one of those is usually true, and finding out which one after the deposit is paid is a common source of delay.

Integrations the site needs to talk to

Name every system the new site needs to connect to: a payment gateway, an accounting or invoicing platform, an email marketing tool, a CRM, an analytics account, a booking or reservation system, a WhatsApp Business API connection. Each of these can range from a plugin installed in an afternoon to a custom integration requiring API access you don't yet have from the third party. If you don't know yet whether an integration is required, say that too — an unresolved "maybe" is more useful to a vendor than silence, because it lets them flag the risk in the quote instead of assuming it away.

Language requirements

If the site needs to serve content in more than one language — commonly Bahasa Malaysia, English, and sometimes Chinese for a Malaysian business — say which pages need which languages, whether translation already exists, and whether it needs to be a fully separate URL structure per language or a simpler toggle. Multilingual sites carry real technical decisions (URL structure, hreflang tagging, translated form validation messages) that a single-language quote won't have priced in, and retrofitting a second language after launch is usually more expensive than planning for it from the start.

Accessibility expectations

State plainly whether the site needs to meet a specific accessibility standard, and to what level. The relevant reference is the Web Content Accessibility Guidelines (WCAG) 2.2, the current W3C standard, with Level AA — the level most laws and procurement requirements anchor to — sitting above baseline Level A and below the stricter Level AAA. If the site needs to serve a government tender, a corporate procurement process, or a genuinely broad public audience, ask directly whether WCAG 2.2 AA conformance is required, because building to that standard from the start is a different (and usually cheaper) exercise than retrofitting it after launch.

Hosting and who owns what

Decide, before quoting starts, who will hold the hosting account, the domain registration, and the source code once the project is done — you, the vendor, or a mix. There's no universally right answer; a vendor-managed hosting arrangement can be entirely reasonable if the terms are clear. What causes problems later is not deciding this upfront and discovering, only when the relationship ends, that a login you assumed was yours was never actually issued to you. State your expectation in the brief, even if it's simply "we want full ownership of hosting, domain, and code from day one" — that alone changes how a vendor should quote and set the project up.

Launch constraints

Note any date the site genuinely must be live by — a product launch, a trade show, a financial year-end — and be honest about whether it's a real deadline or an aspirational one, because vendors price and sequence work differently depending on which it is. Also flag anything else time-bound: a domain or hosting contract expiring, an existing vendor relationship ending on a specific date, seasonal periods when your team won't be available to review drafts or supply content.

Why an unclear brief makes quotes impossible to compare

None of the sections above are difficult to write. What they have in common is that each one removes a silent assumption a vendor would otherwise have to make on your behalf — and every vendor makes a different assumption. That's not a sign of dishonesty on anyone's part; it's what happens when the same three words are handed to four people and each fills the gaps with their own best guess. A brief covering the areas above doesn't guarantee identical quotes — it guarantees that when the numbers differ, they differ because of a real difference in approach, not because nobody was answering the same question.

Getting a brief looked at before it goes out

If you'd like a second pair of eyes on a draft brief before it goes to vendors — checking whether it's specific enough to get comparable quotes back — that's a conversation worth having before any commitment. Depending on scope, JagaWeb's own build options are the Starter Website (from RM8,000, excluding SST) for a defined, template-based site, or a Fixed-Scope Project (from RM30,000, excluding SST) for custom builds and more involved integrations. Either way, a clear brief along these lines is the starting point, not an afterthought.