Start with one clear business outcome
Describe the problem the website should solve before listing features. A service business might want visitors to understand its work and send a relevant enquiry. A supplier might need a clear product catalogue that helps customers request a quotation. These are different jobs, even if both websites use similar page layouts.
Write down who the website is for, what those people need to know, and the main action they should take. Separate a business outcome from a design preference. A dark homepage is a preference; helping a visitor choose the right service is an outcome. Include both in the brief, but make the outcome the basis for decisions.
- Primary audience: who will use the website?
- Main task: what should visitors be able to do?
- Success signal: what useful activity will you review after launch?
Map the pages and the visitor journey
List the pages you expect to need and give each one a purpose. A small service website might include a homepage, service information, an about page and a contact page. Add separate service pages when each service needs its own explanation. Avoid creating pages simply to make the website look bigger.
Follow a realistic visitor journey. Someone arriving on a service page should be able to understand the offer, see relevant evidence and find the next step. Explain which pages should connect to each other. This is more useful than handing over a navigation list without saying why each destination matters.
Separate launch requirements from later ideas
For each feature, describe the actual workflow. Instead of asking for a booking system, explain whether visitors request a preferred date or reserve an available slot immediately. Say who receives the request, whether payment is involved, and what confirmation the customer should receive. Those details change the scope.
Use two lists: essential for launch and possible later. Features such as customer accounts, online payments and file uploads need more decisions than a simple contact path. Ask your developer to explain dependencies and recurring costs before you agree to them. A focused first release can still leave room for future development.
- Describe what the visitor submits and what happens next.
- Name any existing tools the website must connect to.
- Record which features can wait until after launch.
Prepare content and name the decision maker
Identify who will supply service descriptions, brand assets, photographs and any case studies you are allowed to publish. Mark material as ready, needing revision or not yet available. If you need writing or image preparation included, put that in the brief so the quote reflects the work.
Choose one person to collect feedback and confirm decisions. A developer can work through differing opinions, but conflicting approvals can stall a project. Agree how feedback will be delivered and when content will be ready. Share design references with a short explanation of what you like, rather than asking for an exact copy.
Agree ownership and handover before development
Include ownership in the brief from the beginning. State who will own the domain, repository, hosting account and business data, and what documentation you expect. For Cholbei projects, the aim is an independent website deployed in client-owned accounts, with the agreed code and setup handed over.
Discuss licences separately from ownership of custom work. A paid font or template may have conditions that still apply after delivery. Also clarify whether maintenance is included, optional or separately quoted. Knowing what you will receive at the end helps you evaluate proposals before work begins.
Use the website handover checklist to define your deliverables
Use this short brief to request a quote
A budget range and a preferred launch date help your developer suggest an achievable scope. Explain any fixed deadline and why it matters. Ask for the proposal to identify assumptions, exclusions, review stages and the process for changes. A package can provide a starting point, but your requirements determine the agreed work.
Copy the checklist below into a document and answer it in plain language. Where you are unsure, write down the question rather than guessing a technical solution. The brief should open a useful conversation and become a reference for delivery, not prevent the project from evolving through agreed decisions.
- Business, audience and main website outcome.
- Required pages and the purpose of each page.
- Essential workflows, integrations and later ideas.
- Content readiness and the person approving decisions.
- Budget range, preferred date and known dependencies.
- Account ownership, launch checks and handover requirements.
Discuss your website
Tell Cholbei about your goals, required features and timeline.
Contact Cholbei