A useful website quote starts with a useful brief. “I need a professional website—how much?” forces every developer or agency to estimate a different project. Send the same goals, pages, content status, functions, integrations, ownership requirements, and timeline to each provider so you can compare scope rather than unrelated totals.
Copy the template below, remove sections that do not apply, and mark unknown decisions for discussion.
Copyable website project brief
Project name:
Company or organization:
Contact person and decision makers:
1. Business and audience
- What does the business sell or provide?
- Which countries, languages, and customer groups should the website serve?
- What should a qualified visitor do: enquire, request a quote, buy, book, register, or use a workflow?
- What measurable result would make the project successful after 3, 6, or 12 months?
- Which visitor questions or objections must the website answer?
2. Current situation
- Current website URL, if any:
- What is working well?
- What must be fixed or replaced?
- Are the domain, hosting, analytics, Search Console, and source files accessible?
- Approximate number of indexed URLs, articles, products, users, orders, forms, and media files:
- Existing traffic or conversion patterns that should be protected:
- Known technical, content, legal, accessibility, or operational problems:
3. Project type
- Landing page / business website / WordPress / ecommerce / custom application / redesign / migration
- Required pages, templates, product categories, or workflows:
- Required languages:
- Must-have launch scope:
- Important second-phase scope:
- Optional ideas that should not affect the first quotation:
Page or template inventory:
- Name / purpose / audience / primary action / unique or reusable template / content owner / language status
4. Content and brand
- Is approved copy ready?
- Are translation, logo, colors, fonts, photos, video, products, policies, and case studies ready?
- Who supplies and approves each item?
- Which existing content must be kept, rewritten, redirected, archived, or deleted?
- Are all fonts, photos, video, illustrations, and testimonials licensed for the intended use?
- Source language and translation approval process:
- Final content-delivery format and deadline:
5. Functions and integrations
- Forms, WhatsApp, CRM, email marketing, booking, maps, search, accounts, payments, shipping, tax, reports, APIs, or other requirements:
- Existing providers that must remain:
- User roles and permissions:
- Success, validation, failure, notification, and recovery behavior for each workflow:
- Data that enters or leaves each provider:
- Sandbox, documentation, and production access available:
6. Ecommerce, membership, or application operations (if applicable)
- Products, variants, subscriptions, stock, shipping regions, tax, coupons, and refunds:
- Account creation, login, password recovery, permissions, and data export/deletion:
- Payment success, failure, cancellation, and webhook requirements:
- Manual steps that will remain with the business team:
- Required imports, reports, dashboards, or audit history:
7. Quality and measurement
- Mobile and browser requirements:
- Accessibility requirements:
- SEO foundations, redirects, analytics, events, and Search Console requirements:
- Performance or security constraints:
- Required consent, privacy, retention, cookie, or legal review:
- Conversion events and how each will be tested:
- Acceptance criteria for primary pages and workflows:
8. Migration and launch
- Existing URL, content, product, user, order, and media inventories:
- Redirect and metadata preservation requirements:
- DNS, email, SSL, database, and environment dependencies:
- Backup, migration rehearsal, rollback, and launch-validation requirements:
- People who must be available at launch:
9. Hosting and ownership
- Current or preferred hosting:
- Required client-owned accounts and access:
- Required source files, repository, documentation, training, and backups:
- Third-party or reusable assets that cannot be transferred:
- Required export format and exit process if the supplier relationship ends:
- Access that should be removed after handover:
10. Roles, timeline, and budget
- Target launch date and why it matters:
- Internal review availability:
- Approximate budget range:
- Client project owner and final approver:
- Content, translation, legal, IT, and finance owners:
- Expected review window and method for consolidated feedback:
- Fixed external dates or provider approvals:
11. Support
- Warranty expectations:
- Ongoing maintenance, monitoring, reporting, or content support required:
- Required support hours, response expectations, and escalation route:
- Who will apply CMS, plugin, dependency, or hosting updates?
Please include in the quote:
- Deliverables and exclusions
- Milestones and payment schedule
- Client responsibilities and dependencies
- Technology and important third-party licenses
- Testing and acceptance checks
- Launch and handover process
- Warranty and optional maintenance
- Estimated timeline and total cost
- Assumptions that could change the estimate
- Annual third-party renewals and who pays them
- VAT, tax, currency, payment fees, and other applicable commercial terms
- Termination and partial-handover processWhy include a budget range?
A range helps the provider recommend a realistic route. It does not mean the quote must consume the budget. Without it, you may receive a generic theme estimate, a custom-build estimate, and an agency program estimate that cannot be compared.
If you are not ready to share a number, state which option you need: minimum viable launch, recommended professional scope, or phased roadmap. Read the freelance web developer cost guide first.
Define the business outcome
“Modern website” is not a measurable outcome. State what the page must help a visitor understand and do. Examples include requesting a qualified quotation, booking a consultation, completing a purchase, finding a location, registering, or using an internal workflow.
This decision influences navigation, content, proof, forms, analytics events, and acceptance criteria.
List templates and workflows, not only page count
A 20-page website may use four reusable templates. A five-page application may contain complex roles and states. List service pages, case studies, articles, products, checkout, dashboards, user roles, reports, and integrations separately.
Make content responsibility visible
Name who writes, translates, supplies, approves, uploads, and maintains copy, media, products, and policies. If the provider must create or edit content, ask for that work as a separate deliverable.
For bilingual projects, define the source language, translation approval, page pairing, and workflow for future updates.
Ask for ownership in the original quote
Do not wait until final payment to discuss domain, hosting, code, design, content, licenses, analytics, Search Console, data, backups, and provider accounts. Link the brief to the website ownership after development guide.
Compare quotations in one table
Create columns for each provider and rows for:
- Total price and payment milestones.
- Pages, templates, workflows, and integrations.
- Content and language responsibilities.
- Design method and editing experience.
- Mobile, accessibility, performance, security, and search checks.
- Hosting, licenses, renewals, and provider fees.
- Ownership, handover, training, backups, and documentation.
- Timeline assumptions, warranty, maintenance, and exclusions.
A blank cell is a question, not an included deliverable.
Add acceptance criteria before development starts
Acceptance criteria turn adjectives into checks. Replace “responsive website” with statements such as: primary navigation works at agreed mobile widths; forms show labels, validation, success, and failure feedback; approved content appears in both languages; named conversion events are visible in the client-owned analytics property; and the client can create a new article using the documented workflow.
For ecommerce, include successful and failed payment, shipping rules, stock changes, order emails, refund responsibilities, and test-order cleanup. For a migration, include redirect sampling, priority URL status, metadata checks, form delivery, and analytics continuity. The criteria should focus on important outcomes rather than prescribing every implementation detail.
Include one completed scope example
Here is a compact example for a small bilingual company website:
| Brief field | Example answer |
|---|---|
| Business outcome | Generate qualified quotation requests for two core services |
| Audience | Saudi business decision makers; Arabic first, English equivalent |
| Templates | Homepage, service, case study, article, about, contact, legal |
| Launch pages | 6 core pages per language plus 3 existing case studies |
| Content | Client supplies Arabic draft and proof; provider structures and enters approved Arabic/English copy |
| Main workflow | Quotation form routes to sales email, records analytics event, and shows a clear confirmation |
| Integrations | WhatsApp contact, analytics, Search Console; no CRM in phase one |
| Migration | Preserve 12 existing URLs with an approved redirect map |
| Ownership | Client domain, hosting, analytics, Search Console, CMS admin, repository, and backups |
| Acceptance | Mobile/desktop review, keyboard form completion, form-delivery test, metadata and redirect checks |
| Not included | New logo, photography, CRM automation, paid media, ongoing translation |
This example is detailed enough to compare proposals while leaving room for the provider to recommend implementation choices.
Separate requirements from solution preferences
Write “editors need to publish bilingual case studies without code” as the requirement. “Use plugin X” is a solution preference unless an existing license or technical policy makes it mandatory. This allows a developer to propose a safer or simpler route and explain the tradeoff.
When a technology is mandatory, state why: internal team skills, current hosting, integration compatibility, procurement policy, data location, or continuity. Ask the provider to identify any conflict between the requirement and the desired outcome.
What to do when important information is unknown
Mark the item as unknown, name who can answer it, and ask the provider whether it requires discovery. For a legacy site, unknown database quality or undocumented integrations may justify a paid audit before a fixed implementation quote. Discovery should produce reusable outputs such as an inventory, requirements, risks, recommended approach, and estimate assumptions.
Avoid requesting a fixed price while hiding uncertainty. Providers will either add contingency, exclude the risk, or make incompatible assumptions. A visible unknown is safer than a false answer.
Run a quotation clarification round
After proposals arrive, return one consolidated list of questions to each provider. Ask them to update the written proposal when an answer affects scope, price, ownership, or schedule. Do not rely on a sales-call promise that never reaches the agreement.
Compare the proposed outcome, not merely the total:
| Comparison area | Provider A | Provider B | Confirmed decision |
|---|---|---|---|
| Launch templates and content entry | |||
| Languages and translation responsibilities | |||
| Workflows and integrations | |||
| Migration, redirects, and analytics continuity | |||
| Testing and acceptance evidence | |||
| Client-owned accounts and handover | |||
| Build cost and third-party renewals | |||
| Warranty, maintenance, and urgent support |
If the offers remain different, ask for alternatives: essential launch, recommended scope, and future phase. This reveals what each provider would remove or protect under budget pressure.
Frequently asked questions
How detailed should the brief be?
Detailed enough that providers estimate the same outcome and dependencies. Unknowns can remain, but they should be named for discovery.
Should I include example websites?
Yes, but explain what you like: navigation, tone, content structure, interaction, or visual direction. Do not ask for an unexplained copy.
Is the brief a contract?
No. It supports discovery and quotation. The final agreement should convert approved scope into deliverables, responsibilities, milestones, acceptance, ownership, and commercial terms.
Where should I start if I do not know the project type?
Review the web development services hub or send the business goal and current situation for a scoped recommendation.
