Check the scope before the price
Confirm whether research, UX, copywriting, translation, photography, migration, redirects, analytics, schema, hosting, licenses, and post-launch support are included. A proposal that omits these items can appear cheaper while leaving substantial work unresolved.
Ask how many unique templates are included and which features are custom. A page count alone does not describe the actual design or engineering effort.
| Proposal area | What should be explicit | Risk when missing |
|---|---|---|
| Objectives and measurement | Priority outcomes, audiences, conversions, analytics, and success review | A visually complete site with no agreed business result |
| Experience scope | Research, sitemap, journeys, wireframes, responsive design, accessibility, and Arabic UX | Important planning work assumed or omitted |
| Content | Copywriting, translation, migration, entry, media, metadata, and approvals | Launch delays and unexpected client workload |
| Technology | Platform, hosting, integrations, environments, security, performance, and licenses | Hidden dependencies and recurring costs |
| Quality assurance | Browsers, devices, accessibility, forms, integrations, redirects, analytics, and acceptance | Defects discovered by users after launch |
| Commercials | Price, VAT, payment milestones, assumptions, exclusions, change control, and renewal costs | Incomparable bids and budget drift |
| Ownership and support | Code, design, accounts, warranty, service levels, documentation, training, and handover | Supplier dependency and unclear post-launch responsibility |
Business objectives and success measures
The proposal should explain what the website must improve: qualified leads, ecommerce revenue, applications, bookings, self-service completion, brand trust, recruitment, publishing efficiency, or another defined outcome. It should identify the users and journeys that support those outcomes.
Measurement should include the analytics and events to configure, who owns reporting, and when performance will be reviewed. Avoid promises of guaranteed rankings or conversion increases without baseline data, scope, and a credible method.
Delivery plan, team, and responsibilities
Look for phases, outputs, review dates, dependencies, and acceptance points. The proposal should name the strategic, design, content, technical, and project leads or at least describe their seniority and allocation. Confirm whether work is in-house, subcontracted, or dependent on another office or timezone.
A responsibility matrix should show who supplies content, approves Arabic, grants system access, reviews security, tests integrations, and authorises launch. Timelines are unreliable when client responsibilities are invisible.
- Named project owner and escalation route on both sides.
- Review rounds and response windows for each major deliverable.
- Dependencies for content, APIs, legal review, procurement, and infrastructure.
- Definition of done and acceptance criteria for each phase.
- Process for recording decisions, risks, and scope changes.
Arabic, content, SEO, and migration scope
For a Saudi website, the proposal should distinguish Arabic copywriting, translation, localization, RTL design, terminology review, content entry, and language QA. It should explain whether English and Arabic pages are delivered together and who resolves content differences.
Migration scope should list source systems, content types, approximate volume, data cleaning, media, metadata, redirects, and validation. Search foundations should cover crawlable content, titles and descriptions, canonical behavior, structured data where appropriate, sitemap, redirects, and analytics continuity.
Technology, quality, and launch details
The proposal should identify the platform and hosting model, major extensions, custom development, integrations, environments, deployment method, browser and device support, performance approach, backups, monitoring, and security responsibilities. Brand names alone do not describe an implementation.
Launch scope should include content freeze, acceptance testing, redirects, analytics verification, form routing, DNS or deployment responsibility, rollback planning, training, documentation, warranty, and early-life monitoring.
Make ownership explicit
The proposal should explain ownership of code, design files, content, domains, analytics accounts, and third-party subscriptions. It should also define the warranty period and the process for support after that period ends.
Confirm access to the source repository, design workspace, hosting, CMS administration, analytics, tag management, search tools, domains, email services, and vendor accounts. State what can be exported and how handover works if the relationship ends.
A fair scoring method for shortlisted proposals
Create a weighted scorecard before final presentations. Score understanding of the brief, relevant evidence, proposed approach, team, Arabic and content capability, technical solution, delivery confidence, support, commercial clarity, and total cost. Weight criteria according to the risk and purpose of the project.
Record clarifications in writing and require revised proposals where answers change scope or price. The final recommendation should explain tradeoffs rather than simply reporting the highest score.
Common questions
How many website proposals should a company request?
Three well-qualified proposals are often enough for a meaningful comparison. A very large list consumes evaluation time and encourages shallow responses. Pre-qualify suppliers using relevant evidence, capacity, and required capabilities.
Should agencies be paid for a pitch?
For a normal proposal, usually not. If you require substantial speculative strategy, original creative work, or a detailed technical discovery before appointment, a paid discovery or pitch can produce better work and fairer ownership terms.
What is a website proposal red flag?
Common red flags include unclear scope, no named team, guaranteed rankings, a timeline with no client dependencies, heavy upfront payment without milestones, unexplained recurring fees, no ownership terms, and no process for testing or change control.