A useful website brief describes a business situation, not a technology preference. Before asking for a quote, establish what a visitor needs to understand and what they should be able to do. This gives competing suppliers a shared outcome to estimate.

Define the visitor’s next action

A service company may need an enquiry containing enough context for a useful first conversation. A distributor may need a product-specific quote request. A booking business may need a confirmed reservation. Each outcome requires different information and different operational support.

Write down where the visitor arrives from, what they already know and what might prevent them from proceeding. This helps decide which pages deserve their own content rather than being hidden inside a general company description.

Count templates and behaviours

Twenty articles using one template are not the same as twenty bespoke interactive pages. List the types of pages and the behaviour each one needs. Search, filtering, forms and account access all add requirements beyond visual layout.

For every important form, describe success and failure. What happens when a downstream system is unavailable? Who receives the enquiry? A reassuring success message is only useful if the request is actually accepted or delivered as described.

Assign content ownership

  • Who writes and approves service descriptions?
  • Who supplies photographs and confirms usage rights?
  • Which languages are required at launch?
  • Who maintains translations after an offer changes?
  • What should editors be able to update without a developer?

Missing content is a planning dependency, not a minor detail to solve on launch day. Make it visible in the estimate and schedule.

Compare complete proposals

Separate discovery, design, development, content preparation, integrations and launch work. Ask each supplier to state assumptions and exclusions. An estimate that assumes a finished API cannot be compared directly with one that includes building it.

Include recurring costs such as hosting, licences and support. Confirm who owns the accounts and how the project can be handed to another team. The relevant question is not just what the first release costs, but what operating it requires.

Agree acceptance before development

Use observable scenarios: a visitor can find the appropriate service, submit a valid enquiry and receive an accurate confirmation; an editor can change agreed content without breaking the layout. Add relevant device, accessibility and language requirements.

For an existing site, preserve useful URLs or plan appropriate redirects. A redesign should not accidentally remove the pages that answer customers’ questions.

See our website development service for the delivery approach, or prepare a project brief to discuss your scope with CodexLabs.