A useful website quote depends on a useful description of the work. A request for a modern site leaves important questions open, from the number of page types to who prepares the content and how enquiries reach your team.
You do not need to specify every technical detail before speaking to a provider. You do need enough context to distinguish essential requirements from preferences and to compare proposals on the same basis. A structured brief makes that conversation much more productive.
Start with the business change
Describe what needs to improve in business terms. Perhaps customers cannot understand your service range, staff repeatedly answer delivery questions or an old contact form loses useful context. Explain the current situation and the desired behaviour. Include your primary audience and market, because a catalogue for trade buyers differs from a public information site. Avoid selecting a technical solution before describing the problem; the brief should leave room for a simpler approach.
List page types and content responsibilities
Separate unique layouts from repeated content. Ten articles using one template do not represent the same design work as ten distinct interactive pages. List services, project pages, product categories and languages, then identify who supplies text, images and approvals. Existing content may require rewriting or migration. Note whether you have permission to use each asset. Missing material can affect delivery just as much as development, so make content ownership explicit.
Describe functionality with user journeys
Replace vague feature names with a short scenario. For example: a visitor selects a service, sends a request with an attachment and receives a confirmation while the team sees the request in its existing system. State which steps are essential and which could wait. For integrations, name the current tools and available access. Mention unusual cases such as large files or multiple recipients so they can be discussed before work starts.
Include the existing technical situation
Share the current website, domain arrangements and hosting context without sending passwords in the initial brief. Explain whether addresses must remain available, whether email depends on the domain and whether other systems use the site. If analytics or search data exist, they may help identify important pages. A redesign often includes redirect planning and content preservation; treating it as a completely empty site can hide necessary work from the quote.
Compare deliverables and assumptions
Read proposals for their included work, dependencies and exclusions. Ask how revisions, content entry, accessibility considerations, technical SEO and testing are handled. Establish what happens when requirements change after approval. A comparison table can list each deliverable and its owner without reducing every decision to a headline price. Check what you receive at handover, which third-party services require separate accounts and who owns the resulting assets and access.
Plan what happens after launch
A website continues to need content updates, software maintenance and operational attention. Clarify who checks forms, renews services and responds when an integration fails. Describe any editing tasks your team expects to perform independently. The launch plan should include approval, checks and a way to report problems. If you have a preferred date, explain the business reason and any fixed dependency so the provider can assess feasibility rather than assume a guarantee.
Prepare a comparison worksheet
Create one row for each requirement and columns for included work, supplied material, responsible person and open questions. Add an example where wording could be ambiguous: product import might mean a one-time upload or a continuing synchronisation. Ask providers to clarify the same scenario. This simple worksheet makes differences visible and gives the eventual project a starting point for acceptance checks. Update it when scope changes so the approved version remains a useful reference.
Attach examples of websites only with an explanation of the feature you find useful. A reference may illustrate navigation, reading order or product comparison without implying that its entire design must be reproduced.
- State the business problem and audience.
- List page types and required languages.
- Assign content and approval responsibilities.
- Describe integrations through concrete scenarios.
- Compare launch and maintenance scope.
A clear brief reduces ambiguity before it becomes rework. Share the facts you know, mark open decisions and separate essentials from future ideas. Latech can use that information to discuss an appropriate scope for a website, shop or connected workflow.