How to Write a Design and Website Development RFP

Many companies ask three vendors for proposals but provide only one sentence: “We need a premium corporate website; please send a solution and quote.” Each vendor then makes different assumptions about pages, content, the CMS, languages, motion, and deliverables. One proposal may cover only UI, another front-end development, and a third the CMS, copywriting, and maintenance. The prices are not comparable, and disputes later arise over what each party assumed was included.

An RFP establishes a common set of questions and a consistent response framework. It does not need to predetermine every design answer, but vendors must understand the business goals, scope boundaries, technical conditions, evaluation process, and areas where professional judgment is expected.

01 Distinguishing between RFP, request for proposals and contracts

Small projects could combine RFPs with demand letters, but the contracts could not be entirely replaced by chat records. Large procurement may also involve a formal bidding process that should follow the enterprise system and applicable law.

02 Part One: Project Background and Business Goals

Do not begin with a page count. First help vendors understand why the project exists.

Recommended Content

• Company, brand, and core business overview;
• Current product, website, or design-system status;
• Reason for the initiative and its trigger;
• Primary users, markets, and buying contexts;
• Business problems the project should improve;
• Nonnegotiable brand, technology, or compliance constraints;
• Dependencies on other projects, systems, or launch dates.

Goals Should Support Clear Decisions

Too Vague:

>builds an international, high-end, technologically sensitive website.

More Actionable:

>allows overseas manufacturing buyers and engineers to find product lines within three steps, compare key parameters, download data sheets and submit model-specific inquiries; and retain URLs with search value from the current website.

Not every goal must be numeric, but each should guide scope and acceptance.

03 Part Two: Users, Tasks, and Success Criteria

List the most important user groups instead of writing only “business customers.” Examples include prospective buyers, engineers, channel partners, existing customers, job candidates, and the media.

Success criteria may cover task completion, content maintainability, mobile experience, lead quality, performance, preservation of indexed pages, and on-time delivery. Do not promise traffic growth unless the company has a reliable baseline and supporting channel investment.

04 Part III: Scope of the project and list of pages

The page range is counted simultaneously as " Page Template " and " Number of Contents ". For example, there is only one template for news details, but 200 content may need to be migrated; there may be three completely different templates for product details.

Proposed Fields for Page List

If the page inventory is not final, provide a range and ask the vendor to confirm it during discovery—for example, “an estimated 12–16 templates and 40–60 static content pages.”

Clear exclusion

For example:

• Re-establishment of brand strategy and Logo;
• Photography, video, 3D and illustration production;
• (b) A full copy in Chinese;
• Professional legal and privacy counselling;
• CRM or ERP prototype development;
• Historical data cleansing;
• Domain names, servers and third-party subscriptions;
• Ongoing SEO operations and link building construction.

Exclusions do not avoid responsibility; they prevent vendors from pricing different assumptions.

05 Part Four: Functions and operational rules

Not just "search, form, membership." Each function describes at least the user, input, outcome, anomaly and admin responsibility.

Function Description Template

For complex features, attach flowcharts or screenshots of the current system. Mark unresolved rules as “to be defined jointly with the vendor during discovery” and state the allowance included in the scope.

06 Part V: Content, branding and asset responsibility

The design project is often extended from content. RFP should state:

• (a) The existence of branding, font authorization and design assets;
• Who writes, translates and approves Chinese, English and French;
• Who provides the products, cases, teams, qualifications and legal texts;
• Images, videos, icons and illustrations are based on existing assets, libraries or originals;
• How many historical pages, articles, products and documents need to be migrated;
• Whether vendors are responsible for content strategy, editing, recording and proofreading;
• The content is frozen, updated and finally confirmed.

07 Part VI: Technical and non-functional requirements

Technical requirements should not be limited to “responsive, fast, SEO friendly”. Target environments and verifiable standards should be specified.

Suggested Overwrite

• Existing domain names, servers, cloud platforms and technology stacks;
• Whether to specify CMS, front-end frameworks or systems that must be compatible;
• Browsers, devices, screens and regions;
• Content roles, privileges, versions, approvals and rollbacks;
• Integrated forms, CRMs, mail, analysis, maps, videos, etc.;
• Performance, cache, image, CDN and monitoring;
• (a) Accessibility objectives and scope of testing;
• Security, privacy, logs, backup and recovery;
• Test environment, production environment, deployment and code repository;
• Future multilingual, multi-regional and system expansion.

Don't assign technology that's not justified.

If the company has no framework-specific maintenance requirement, the RFP should not mandate a particular front-end technology. Instead, require source code, reusable components, deployment to the existing environment, and maintainability by the internal team, then ask vendors to explain their recommendation and tradeoffs.

08 Part VII: SEO and website migration requirements

If the old station is modified, SEO cannot simply write "Submit search engine". At least:

• Retain existing high-value URLs, titles and content signals;
• Provides old URL to the new URL map and permanent redirect;
• Canonical URLs, sitemaps, robots directives, and indexing;
• Each page edits Title, Description, H1 and social tags;
• Multilingual independent URLs and language relations;
• Structured data is consistent with the real content of the page;
• Page performance, mobile experience and graphic specifications;
• Search Console, analytics, and conversion tracking;
• Pre- and post-launch crawls, 404, redirect and index monitoring;
• Clear basis for the boundaries between technical SEO delivery and ongoing SEO operations.

The RFP should also provide existing organic traffic, key pages and known SEO issues to enable vendors to assess migration risks.

Part VIII: Delivery and intellectual property

“Delivering website” is too vague. The recommendations are itemized:

The intellectual-property section should distinguish final work, rejected concepts, third-party fonts, images, templates, plugins, open-source code, and the vendor’s preexisting tools. The contract should state when rights transfer, the scope of that transfer, and when source files and code will be delivered after final payment.

10 Part IX: Schedules, milestones and mutual responsibilities

The RFP may give a target date launch, but the vendor should be allowed to account for dependency and risk.

Suggested Milestones

1. Project initiation and information availability;
2. Needs and page range confirmation;
3. News and Insights architecture and prototype confirmation;
4. Visual direction confirmation;
5. Full design confirmation;
6. Development build review;
7. Content migration and testing;
8. Launch and stabilization monitoring;
9. Source files, code, and accounts are handed over.

Also define the client’s feedback deadlines, final decision-maker, content-delivery obligations, and responsibility for technical integrations. State how delays in client materials or added scope will affect the schedule.

11 Part Ten: Budget and Pricing Format

Publishing a budget range usually reduces vendor mismatch and encourages realistic proposals. If the company cannot disclose a budget, at least require every vendor to use the same pricing breakdown.

Vendor proposals

Require vendors to disclose taxes, payment milestones, travel, fonts, stock assets, cloud services, plugins, and recurring subscriptions. Compare scope, team, responsibilities, and long-term cost—not just the total price.

Part XI: Require vendors to communicate in a uniform format Response

The vendor proposal answers at least:

1. Understanding of project objectives, users and key risks;
2. Recommended methodologies, phases and key decision-making;
3. Project teams, roles, inputs and actual participants;
4. 2-3 related cases and coverage of real services;
5. Pages, functions, content and technical options;
6. (a) Milestones, duration and client cooperation requirements;
7. Delivery, acceptance and quality assurance;
8. Proposal, assumption and change in pricing;
9. Third-party dependence, intellectual property rights and preservation;
10. Main risks, issues to be identified and alternative recommendations.

When every proposal uses a different structure, polished presentation can distract reviewers from scope differences. A consistent response framework preserves room for creative thinking while making proposals easier to compare.

13 Part Twelve: 100-Point Vendor Evaluation Scorecard

Suggested Disqualifying Criteria

• The actual project team cannot be described;
• (a) The case cannot verify the scope of the service;
• Failure to provide source files or code boundaries;
• Use of third-party assets without authorization;
• Guaranteeing fixed Google rankings or failing to explain the SEO method;
• The proposal omits assumptions and exclusions;
• No testing, launch, backup, or handover plan;
• Key data or accounts must be permanently controlled by the vendor.

Part XIII: Communication, question and answer and proposal process

Recommended process:

1. Publication of RFP and opening of the Unified Questioning Window;
2. Synchronize key responses to all candidates;
3. Allow vendors to present clarifications and alternatives;
4. (a) Written responses before proposals for shortlists are scheduled;
5. The proposal will require the participation of the actual project team;
6. Conducting case verification and customer reference;
7. Final clarification of scope, price and contract;
8. Inform the results and enter the onboarding plan.

Do not ask a large group of vendors to produce complete design concepts for free. For high-risk projects, use paid discovery, a workshop, or a proof of concept so the selection reflects real collaboration rather than a one-time pitch.

15 Reusable RFP Outline

1. Project name and document version;
2. Corporate and business background;
3. Project causes and objectives;
4. Users, markets and key tasks;
5. Current websites, systems and known problems;
6. Pages, templates, content and language ranges;
7. Functions and rules of operation;
8. (a) Branding, copy, photographic and information responsibilities;
9. Technology, CMS, integration and environment;
10. SEO, migration, performance and accessibility;
11. Privacy, security and industry requirements;
12. Delivery, source files, codes and intellectual property rights;
13. Project schedule, milestones and feedback mechanisms;
14. Budget, payment and proposal formats;
15. Vendor qualifications and response formats;
16. Evaluation criteria, processes and key dates;
17. Contracts, maintenance, exit and confidentiality;
18. Annex: Page lists, processes, brand codes, data and available reports.

16 Self-Check before RFP release

• Can a strange vendor say in one sentence why the project was done?
• Does the number of pages, templates, content and language distinguish?
• Does the function include input, results, anomalies and admin responsibility?
• Who is responsible for the writing, translation, asset and relocation?
• Are technical decisions based on real constraints or personal preferences?
• Are SEO, privacy, performance, and accessibility requirements verifiable?
• Are the deliverables, accounts, source files and codes clear?
• Can the budget cover the desired range?
• Are feedback timelines, decision-makers, and acceptance criteria confirmed?
• Do vendors submit proposals in a uniform format?
• Are scoring weights consistent with business goals?
• What issues allow vendors to propose better alternatives?

Frequently Asked Questions

1. Does a Small Website Project Need an RFP?

A long formal document may not be necessary, but even a small project needs at least a one-page brief covering pages, features, deliverables, schedule, and budget. Smaller projects benefit especially from controlling communication overhead.

2. Should the RFP Disclose the Budget?

Yes, when a clear range exists. Publishing it reduces unsuitable proposals. If the budget cannot be disclosed, require tiered scope options and a consistent cost breakdown instead of one undifferentiated total.

3. Should Vendors Be Asked to Design the Home Page for Free?

Generally, no. Relevant case studies, the proposed approach, the actual team, workshops, and a paid proof of concept provide better evidence of collaboration quality than a complete unpaid pitch.

4. What If the Page Inventory Is Still Unclear?

Provide an estimated range, the existing content, and the business goals. Ask the vendor to confirm the inventory during discovery and state capacity, assumptions, and adjustment rules in its proposal.

5. How Can a Company Prevent Cost Escalation After Award?

Define scope, counting rules, revision rounds, exclusions, and change rates before award. Require every proposal to state its assumptions, and approve the fee and schedule impact of added scope in writing.

6. Should the RFP and Final Contract Be Identical?

No. The RFP is a procurement input, and vendor proposals and clarifications will refine the details. Convert the agreed scope, pricing, deliverables, schedule, and responsibilities into contract exhibits.

Conclusion: The Value of an RFP Is Reducing Hidden Assumptions

The greatest procurement risk in a design or website project is often not a high or low quote, but the fact that the client and vendor are pricing fundamentally different projects. A clear RFP lets vendors propose solutions against the same goals and boundaries, so evaluators can compare actual value rather than portfolios and total price alone.

A mature RFP clearly defines business goals, user tasks, scope, technology, content, deliverables, budget, timing, and evaluation criteria while leaving room for vendors to recommend informed tradeoffs.