A useful website development brief does more than list pages and visual references. It gives a Cape Town business enough precision to compare proposals on the same work, expose important dependencies early, and decide whether a template, a WordPress build, a custom web application, or a phased approach is appropriate.
Start with the business decision the site must support. For example: route qualified enquiries to the right team, accept and fulfil online orders, let customers book a service, or give account holders access to documents. If the answer is only “we need a new website”, suppliers will have to make expensive assumptions about the work.
What a development brief should decide
A brief should settle the decisions that change build effort, risk, and ongoing ownership. The design can still develop through discovery. The basic operating model should not be a mystery.
| Decision area | Write this in the brief | Why it changes the proposal |
|---|---|---|
| Primary outcome | The one action or task the site must make easier, plus how the business will observe it. | It determines journeys, forms, checkout work, analytics events, and acceptance tests. |
| Users and access | Who uses the public site, who edits it, and whether customers, staff, or partners need accounts. | Authentication and role permissions are application work, not a page-layout detail. |
| Content ownership | Which existing content moves, who supplies new copy and assets, and who signs it off. | A migration, content model, and editorial workflow need separate scope. |
| External systems | Named systems, data direction, fields, frequency, error handling, and system of record. | An integration may need an API, middleware, a manual fallback, and monitoring. |
| Performance and accessibility | Relevant user journeys, device conditions, and the accessibility standard or target. | These become testable quality requirements rather than a vague request for a fast site. |
| Operations | Hosting owner, domain and DNS access, backups, updates, support hours, and incident contacts. | A launch is incomplete if nobody can update, restore, or support the site. |
The decision checklist to use before requesting proposals
Copy this checklist into a working document. A supplier can price an unknown item as an assumption, a discovery task, or an option. Leaving it out altogether is where budget surprises tend to begin.
1. State the problem and the boundary
- Describe the customer or staff problem in one sentence.
- Name the primary audience and any separate audiences with different tasks.
- List what this phase will deliver and what it deliberately will not deliver.
- Choose the decision maker who can resolve scope questions.
- Set a launch constraint only when it is real, such as an event, trading date, contract end, or platform retirement.
There is a practical distinction between a marketing website and a web application. A public site with editable pages and an enquiry form may fit a content management system. Customer-specific dashboards, booking rules, document workflows, price calculations, or data synchronisation can introduce application behaviour. Describe that behaviour rather than calling everything a “website”.
2. Make the content work visible
List the page types, not just a total page count. A location page, a case study, a product detail page, and a resource article can have different fields, relationships, and editorial needs. For each type, say whether content will be migrated, rewritten, or created from scratch. Include downloads, video, images, PDFs, redirects, and legal pages.
If an existing site is being replaced, create a URL inventory before development. Google recommends mapping old URLs to new URLs when a move changes URLs, using permanent server-side redirects, and monitoring the move in Search Console. The related WordPress rebuild checklist explains why redirects and pre-launch validation belong in the plan rather than the final hour.
3. Specify integrations as contracts
“Connect it to our CRM” is not a scope. Name the CRM, the trigger, the fields to send or retrieve, the source of truth, the authentication method, rate limits if known, and what happens when the service is unavailable. Do the same for payment gateways, stock systems, email platforms, maps, identity providers, accounting software, and marketing automation.
Ask the supplier to identify which party owns each credential, webhook, API key, domain, and hosting account. A clean handover depends on that answer. Galactic Digital’s technical project management service is relevant when several vendors or systems need a single delivery plan.
4. Turn quality into acceptance tests
Use testable language. “Responsive” could mean a menu works at one width, or it could mean key journeys have been tested on representative mobile devices and browsers. The difference matters.
For performance, Google identifies Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift as Core Web Vitals. Google says site owners should aim for LCP below 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. Those measurements need context: field data reflects real users, while lab tools help diagnose a page during development. A target is useful only when the brief says which page templates and journeys will be tested.
For accessibility, WCAG 2.2 is a W3C Recommendation that adds success criteria to WCAG 2.1. The brief can request a level of conformance, a defined audit scope, keyboard testing for crucial journeys, and a process for fixing findings. Do not treat an automated scan as proof that a whole website is accessible. It will not judge every interaction, alternative text decision, or error message in context.
For security, ask for proportionate requirements. OWASP’s Application Security Verification Standard provides a basis for specifying application security verification requirements in procurement and contracts. A brochure site and a customer portal do not carry the same risk. The brief should identify personal data, account access, payments, privileged administration, and third-party services so the security work can match the system.
5. Define the launch and support handover
List the people who will approve content, design, user acceptance testing, DNS changes, and launch. Then name the rollback decision: who can pause or reverse a release, under what condition, and how the previous working version is restored. Include backup and restore responsibility, monitoring, software-update ownership, and response expectations after launch.
A website can be visually ready while operationally unfinished. If the business cannot edit a price, find a form submission, restore a backup, or contact the person who controls DNS, it has inherited risk rather than a finished system.
A compact proposal comparison matrix
Ask every shortlisted supplier to complete the same matrix. It does not choose a supplier by itself, but it makes omissions visible.
| Question | Supplier response to request |
|---|---|
| What is included in discovery, design, development, content migration, testing, launch, and support? | Separate included work, exclusions, assumptions, and optional items. |
| Which integrations are confirmed and which need technical validation? | Name the systems, owners, risks, and fallback approach. |
| How will acceptance be tested? | List journeys, devices or browsers, accessibility checks, performance measurement, and defect process. |
| What will the client own on handover? | Confirm source code, design files, hosting, domain, analytics, documentation, accounts, and access. |
| What changes if content, integrations, or approvals arrive late? | Explain the change-control process and the effect on scope or launch. |
When a phased build is the safer decision
Use a phased approach when a business knows the problem but has not validated every workflow or integration. Phase one can establish content architecture, core pages, measurement, and a single high-value journey. Later work can add logged-in areas, complex automation, or a customer portal after the organisation has settled the requirements and data ownership.
That is not a reason to hide costs. It is a way to separate confirmed work from work that still needs discovery. The proposal should show the boundary clearly, along with what must be decided before the next phase can begin.
What to send with the brief
Attach current brand assets, existing content inventory, relevant analytics access or exports, integration documentation, legal copy, and a list of stakeholders. Include examples of sites only to explain a behaviour or information pattern, not as a request to copy a visual style. A capable development team will still ask questions, but it should be asking about decisions that matter, not trying to reconstruct the project from a mood board.
If you are planning a build or a rebuild, contact Galactic Digital with the problem, the checklist, and the systems involved. That gives the conversation a technical starting point and makes it easier to decide whether web design, a content-led WordPress build, custom development, or a staged project fits the work.
Bonus: use AI to turn rough notes into a draft brief
AI is useful for organising notes into a first draft. It cannot confirm whether an integration is possible, whether a supplier has understood the scope, or whether a launch plan will work. Give it facts, keep commercial and customer data out of the chat, and make the final decisions yourself.
Paste the prompt below into the AI tool you use, replace the brackets with your information, and answer its follow-up questions. Keep placeholders where a fact is not yet known.
You are helping me prepare a website development brief for supplier proposals. Turn my notes into a clear, practical brief. Do not invent facts. Where information is missing, write "Open decision" and add a specific question I need to answer.
Business and project notes:
- Business and audience: [describe]
- Problem the website must solve: [describe]
- Primary outcome or conversion: [describe]
- Scope for this phase: [describe]
- Explicit exclusions: [describe]
- Existing site, content and URLs: [describe]
- Content owner and approval process: [describe]
- Required pages, features and user journeys: [describe]
- Integrations, data owners and systems of record: [describe]
- Customer accounts, payments or personal data: [describe]
- Brand, legal, accessibility and performance requirements: [describe]
- Hosting, domain, analytics and account ownership: [describe]
- Launch constraint, budget range and decision makers: [describe]
Create the brief using these sections:
1. Project context and business outcome
2. Audiences and the tasks they need to complete
3. Scope, exclusions and phased work
4. Content, page types and migration requirements
5. Functional requirements and integrations
6. Accessibility, performance, security and privacy requirements
7. Analytics and acceptance tests
8. Ownership, handover, support and launch responsibilities
9. Dependencies, risks and open decisions
10. A supplier comparison table that separates included work, assumptions, exclusions, validation work and optional items
Use plain language. Keep requirements testable. Flag vague phrases such as "fast", "modern" or "integrate with our CRM" and replace each one with the question needed to define it.Read the completed brief alongside the proposal comparison matrix above. A good draft gives suppliers enough detail to explain their assumptions. It does not remove the need for discovery or technical validation.
Sources
- Google Search Central, Site Moves and Migrations. Used for URL mapping, redirects, sitemaps, and monitoring during URL changes.
- Google Search Central, Understanding Core Web Vitals and Google search results. Used for the LCP, INP, and CLS metrics and published thresholds.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, published 5 October 2023. Used for the WCAG 2.2 description and conformance context.
- OWASP, Application Security Verification Standard. Used for the procurement and contract requirements claim.
Featured image: Core Organising Team Submission Planning by Open Knowledge Foundation Deutschland licensed under CC BY 2.0.