The first question when ordering a website is often how much it will cost. A useful quotation starts with what the website needs to do. Two projects with the same number of pages can involve very different work: one presents services, while another accepts bookings, creates customer accounts and exchanges inventory data.
A project brief is useful beyond the development team. It helps the business and supplier check that they expect the same outcome. These questions provide a concrete starting point for your first meeting.
1. What is the main goal?
Replace “a modern website” with the visitor's intended action: requesting a quote, ordering a product, choosing an appointment or learning about a service. Choose one primary goal and list secondary goals separately so every button does not compete for the same attention.
2. Who will use the website?
Describe whether customers are individuals or companies, which languages they search in and whether they mainly use phones or computers. “Everyone” offers little design guidance. Someone looking for a repair service needs different information from a purchasing specialist requesting wholesale prices.
3. Which pages are needed?
List the homepage, services, individual service pages, company information, contact page and blog. For a catalogue, specify category and product pages separately. Five pages and hundreds of product cards are not equivalent amounts of work.
4. What journey will the visitor follow?
Describe a sample journey: arrive from an advertisement, read a service, select a package, complete a form and receive confirmation. State when a telephone number or email is requested. This journey can later become an acceptance test.
5. Which features are essential at launch?
Separate launch essentials, later additions and ideas still under consideration. This connects the initial budget to an initial result while allowing future development. A simple enquiry form may be a suitable first step if a shopping cart is unnecessary.
6. Who prepares the content?
Assign responsibility and delivery dates for the logo, text, service list, product photographs, prices and contact details. Adding much longer text to an approved design or importing an incomplete product table may require additional work.
7. Which languages and versions are planned?
If Azerbaijani, Russian and English are required, identify who prepares each version. Agree in advance how translations are produced and edited. Specify behaviour such as opening the equivalent service page when a visitor changes language.
8. What must be integrated?
Name the CRM, payment service, stock system, delivery and notification tools. Mention available access and documentation without placing secret keys in a public document. An available integration and a working data exchange are separate considerations.
9. What will staff manage themselves?
Decide who can change prices, products, services and articles, who can publish and who can view orders. Include training and a short user guide as explicit handover deliverables.
10. How will you accept the result?
Choose testable criteria: a form submits, a test order appears in the account, the mobile menu works and error messages are clear. Agree design approval, revision stages and a test checklist instead of an undefined “until we like it”.
11. Who is responsible after launch?
Assign hosting, domain, backup, maintenance and content responsibilities. Distinguish new features from bug fixes. Explore the scope of support through IT Outsourcing services.
12. How are budget and stages divided?
List the initial release, additional features and monthly service costs separately. The StarWeb project builder can provide an initial calculation by product and features. The final amount is clarified after approval of the brief.
A short example to adapt
Goal: receive consultation enquiries. Audience: small businesses in Baku. Languages: Azerbaijani and Russian. Initial release: service pages, enquiry form and blog. Content: supplied by the company. Integration: send enquiries to a CRM, subject to technical checks. Acceptance: a mobile test enquiry appears in the system and the visitor receives confirmation.
Adapt this example to your business and send it to StarWeb. A clearer description makes the scope and delivery stages easier to discuss.
The cover is an AI-generated illustration.