How to write an RFP for a PH web design project

Most Philippine SMEs skip the RFP and ask three builders for “a quote.” They get back three documents written in three different formats, with three different scopes assumed, three different timelines, and three different inclusion lists. Comparing them is impossible. The buyer ends up choosing the cheapest, the most expensive, or the one whose salesperson called the most. None of those are the right way to choose.

A written RFP fixes this. It forces you to clarify your own requirements before talking to vendors. It produces comparable quotes. It gives you negotiation leverage. And it signals to good builders that you’re a serious buyer who’s worth the time of writing a real proposal.

This article gives you the 10-section RFP structure I’d use for any PH web design project ₱120,000 and above, with a complete worked example for a hypothetical Philippine clinic at the end. Use it as a template — copy it, edit the brackets, send it.

The short answer

A solid PH web design RFP is 5–8 pages, has 10 named sections (business context, audience, current site, scope, success metrics, timeline, budget range, evaluation criteria, submission instructions, contact), and goes to 3–5 vendors with 2 weeks to respond. Include a budget range (skip this and you’ll get unusable quotes), specific deliverables (page count, integrations, performance targets), and at least one conversion-tied success metric. Skip the RFP entirely for projects under ₱50,000; insist on it for projects ₱120,000 and above.

When you need an RFP and when you don’t

Not every project warrants the overhead.

Skip the RFP entirely if your project is under ₱50,000, you already have a builder relationship that’s worked, scope is small (single landing page, simple update), or you only have one specific vendor in mind. A written brief and a quick email exchange are sufficient.

Use a lightweight one-page scope brief for projects ₱50,000–₱120,000. Specify pages, integrations, timeline, budget range. Skip the formal evaluation criteria section. Send to 2–3 vendors.

Use a full 10-section RFP for projects ₱120,000 and above. The investment of time pays back in better proposals, comparable quotes, and a paper trail that protects you in any disagreement later.

Use a procurement-grade RFP (legal review, formal evaluation matrix, multi-stakeholder sign-off) only if you’re a corporation with internal procurement standards. SMEs don’t need this layer; it filters out good solo builders who can’t justify the bid time.

The 10 sections of a working RFP

Here’s the structure. Each section explained, with what to include and what to skip.

Section 1: Business context

A 150–250 word summary of who you are. Industry, size (revenue range or staff count), location, year founded, what makes you different from competitors. The point is to give the builder enough to recommend a solution that fits — not to write your About page for you.

What to include: industry, market position, current challenges, what’s driving the redesign.

What to skip: marketing fluff, mission statements unless genuinely relevant, your competitor analysis.

Section 2: Audience

Who are you trying to reach? Be specific. “Filipino SMEs in Metro Manila, owner-operators aged 35–55, ₱5M–₱50M annual revenue, primarily mobile users, code-switch English/Tagalog.” Not “everyone.”

What to include: primary buyer persona, secondary persona if relevant, where they currently find you (referral, Google, social), device split (mobile-first vs desktop), language preferences.

What to skip: demographic minutiae the builder can’t act on. The audience description should drive design and copy decisions.

Section 3: Current site (audit)

What exists today? Be honest. URL, platform, year built, what works, what doesn’t, current monthly traffic if known, top performing pages if known, top frustrations.

If you don’t have a current site, say so. If you have a “site” that’s a Facebook page, say so. Builders need accurate baselines to estimate migration effort, content portability, and SEO continuity.

What to include: URL (or “none”), current platform (WordPress, Wix, custom, none), current monthly visitors (use Google Analytics if you have it; estimate if not), known issues, content you want to keep vs. discard.

What to skip: subjective complaints without specifics (“it’s ugly” — be specific about what’s ugly).

Section 4: Scope (the most important section)

This is where most RFPs fail. Vague scope produces vague quotes. Specific scope produces comparable quotes.

What to include in scope:

• Page list. Name every page. Home, About, Services, Service Detail (one template, X instances), Blog Index, Blog Post (one template), Contact, Privacy, Terms. Number them. “12 pages” is meaningless without the list.
• Integrations required. GCash, Maya, PayMongo, Mailchimp, HubSpot, Calendly alternative, booking system, CRM, Google Analytics, Google Tag Manager, Search Console, schema markup. Name each.
• Content management requirements. Will the client edit pages themselves? How often? Which pages? This shapes whether the builder uses a page builder, Gutenberg, or a custom CMS.
• Functional requirements. Forms (named: contact form, booking form, newsletter signup), search, multi-language (specify languages), member login, e-commerce (specify product count and category structure).
• Performance requirements. Core Web Vitals targets, mobile-first, accessibility level (WCAG 2.1 AA is standard), browser support.
• SEO requirements. Schema markup type (LocalBusiness, MedicalClinic, Product, Article — name them), sitemap, robots.txt, redirects from current URLs (if migrating), Google Search Console setup.
• Out of scope (explicit). Content writing? (You’re providing it, or builder is.) Photography? Video? Logo design? Stock imagery licensing? Hosting setup? Domain transfer?

What to skip: feature wishlists you can’t justify, “AI-powered” anything unless you genuinely need it, “responsive” as a requirement (it’s table-stakes — say so but don’t pad with it).

Section 5: Success metrics

How will you know the project succeeded? This is where you separate professional builders (who think about outcomes) from order-takers (who just want to ship something).

Standard metrics to include:

• Performance. LCP (Largest Contentful Paint) under 2.5 seconds, INP (Interaction to Next Paint) under 200ms, CLS (Cumulative Layout Shift) under 0.1. Measured on PageSpeed Insights mobile, 75th percentile.
• Mobile usability. Passes Google’s mobile-friendly test, no horizontal scroll on 360px viewports.
• Accessibility. WCAG 2.1 AA compliance on Home, Contact, and one Service Detail page (full-site WCAG audit is enterprise scope).
• SEO foundation. Schema markup validates in Google’s Rich Results test, sitemap submitted to Search Console, redirects in place from old URLs (if applicable), no crawl errors in first 30 days.
• Conversion-tied metric. Define one. “Contact form submissions tracked in Google Analytics 4.” “GCash checkout completion rate measurable in PayMongo dashboard.” “Booking form completion rate.” This is the metric that ties the website to your business.

What to skip: vague aspirations (“best-in-class user experience,” “industry-leading design”). If you can’t measure it, it’s not a metric.

Section 6: Timeline

When do you need this live? Be realistic. Most Business-tier projects take 5–8 weeks from contract signing. If you say “4 weeks” you’ll either get rushed work or no bids.

What to include:

• Target launch date. A specific date.
• Hard deadline (if any). “Must launch before [event/season].” Builders need to know if there’s slack.
• Your availability for feedback. Can you sign off on designs within 48 hours? 5 days? This affects timeline more than people realize.
• Internal stakeholder cycle. Who else has to approve? How long does internal review take?
• Phase expectations. Discovery, design, development, QA, launch. Approximate calendar weeks for each.

What to skip: arbitrary deadlines that create rush premiums for no business reason.

Section 7: Budget range

This is the section most buyers want to skip. Don’t.

Disclose a range. “₱120,000–₱180,000” or “₱220,000–₱320,000.” This isn’t an invitation for builders to bid the ceiling — it’s information they need to scope appropriately.

If your budget is ₱150,000 and the builder thinks you have ₱500,000, they’ll propose Premium-tier features you don’t need and you’ll dismiss them as too expensive when actually they could have served you well at ₱150,000.

If your budget is ₱500,000 and the builder thinks you have ₱150,000, they’ll skip features that you actually want included and you’ll feel underwhelmed by the proposal.

Disclose the range. Get usable proposals.

What to include: a peso range, what’s included in the range (just project work? hosting? care plan?), what’s flexible (could go higher for the right value).

What to skip: false ranges to extract lower bids. Builders eventually figure this out and you burn the relationship.

Section 8: Evaluation criteria

How will you choose a winner? Make this explicit.

Typical weights for a PH SME web RFP:

• Approach and methodology (30%): Does the proposal demonstrate understanding of your business and audience? Is the proposed approach sensible?
• Relevant experience (25%): Have they done similar projects? Can they show portfolio examples?
• Price (25%): Is the price within budget and well-explained (line items, not a single number)?
• Timeline (10%): Can they meet your target?
• Cultural and communication fit (10%): Tone of the proposal, responsiveness during the bid process, alignment on values.

Adjust weights to your priorities. If price matters most, weight it 40%. If you absolutely must launch by a date, weight timeline 25%.

What to include: criteria with weights, what each criterion measures, who’s evaluating.

What to skip: secret criteria you don’t disclose. If “I just had a feeling about them” is a real evaluator, name it.

Section 9: Submission instructions

How do builders respond? Be specific.

What to include:

• Submission deadline. Date and time, specific time zone (PHT/UTC+8).
• Format required. PDF, Google Doc link, web page — pick one.
• Required sections in the response. Approach, scope confirmation/clarification, team and qualifications, similar work examples, timeline, line-item pricing, payment terms, contract template (or willingness to use yours), questions list.
• Page or word limit. “Maximum 10 pages including portfolio examples.” Keeps responses readable.
• Q&A process. Will you answer questions? By when? Will questions and answers be shared with all bidders (good practice for fairness)?

What to skip: requiring proprietary tools (don’t make builders submit through a vendor portal that takes a day to set up) or in-person presentations (skip — written proposals are sufficient for SME projects).

Section 10: Contact and process

Who’s the single point of contact? What happens after submissions?

What to include:

• Single named contact. Name, role, email. Phone is SMS-only if you’re using webdesigner.ph as the model — most PH SMEs default to email or Viber.
• Question deadline and response policy. “Questions accepted via email through [date]. Answers shared with all bidders within 48 hours.”
• Selection timeline. “Shortlist announced [date]. Selected vendor notified [date]. Contract signed [date]. Project kickoff [date].”
• Confidentiality and IP. Standard clause that proposal contents are confidential. Note that submitted proposals don’t transfer IP to you (that happens in the contract).

What to skip: legal NDAs upfront. Save NDAs for the selected vendor at contract stage.

A complete RFP example: PH clinic redesign

Here’s a worked example you can use as a template. The clinic is hypothetical but the structure mirrors a real Business-tier RFP.

---

RFP: Website redesign for [Clinic Name]

1. Business context. [Clinic Name] is a multi-specialty clinic in Quezon City founded in 2018. We see 60–80 patients per day across general medicine, pediatrics, and OB-GYN. We have 4 doctors and 8 support staff. Annual revenue is in the ₱25M–₱40M range. Most patients book by walk-in or phone; we want the new site to drive online appointment booking and reduce phone load on reception.

2. Audience. Primary audience: Filipino patients aged 25–55 in Quezon City and adjacent NCR cities, seeking general/family medicine, pediatrics, or OB-GYN. Predominantly mobile users (estimated 80%+). Code-switch English/Tagalog. Decision drivers: doctor credentials, clinic location/hours, accepted insurance (HMO partners), price transparency on consultation fees.

Secondary audience: HMO partners reviewing our credentials.

3. Current site. [URL]. Built on Wix in 2019. Roughly 800 visitors per month per Google Search Console. Major issues: not mobile-optimized, no online booking, thin doctor profile pages, no Tagalog content, slow on mobile (LCP > 5 seconds), no schema markup. Content to keep: clinic story, doctor names and photos. Content to discard: 2019 health blog posts (outdated).

4. Scope.

Pages required:

1. Home
2. About Clinic (story, mission)
3. Doctors (index page)
4. Doctor Detail (template, 4 instances)
5. Services (index page)
6. Service Detail (template, 12 instances — General Medicine, Pediatrics, OB-GYN, plus sub-services)
7. Online Booking (form-based, integrated with [booking platform])
8. HMO Partners (list of accepted insurance)
9. Contact (location, hours, map, contact form, SMS number)
10. Patient Resources (downloadable forms, FAQs)
11. Blog Index
12. Blog Post (template)
13. Privacy Policy
14. Terms of Service

Total: 14 pages, 4 templates.

Integrations required:

• Online booking system (preference: [system name] or builder recommendation)
• GCash and Maya for consultation deposit payment
• Google Maps embed
• Newsletter signup (Mailchimp)
• Google Analytics 4
• Google Search Console
• Schema markup: MedicalBusiness, Physician, FAQPage

Functional requirements:

• Booking form with date/time picker, doctor selection, reason for visit
• Contact form with department routing
• FAQ accordion on Service Detail pages
• Doctor search/filter on Doctors index
• Mobile-first navigation (hamburger menu, sticky CTA for booking)

Performance requirements:

• LCP under 2.5 seconds on PageSpeed Insights mobile (75th percentile)
• INP under 200ms
• CLS under 0.1
• WCAG 2.1 AA on Home, Booking, Contact pages

Out of scope (explicit):

• Content writing (we’ll provide)
• Doctor headshots (we’ll provide)
• Stock photography licensing (builder to advise on free options or include in budget)
• HMO API integrations (manual list only)
• EHR/EMR integration (out of scope)

5. Success metrics.

• Performance: Core Web Vitals targets above, measurable on PageSpeed Insights at launch.
• SEO: Schema validates in Rich Results test, sitemap submitted to Search Console, all current ranking pages preserved via 301 redirects.
• Conversion: Online booking form submissions trackable in GA4 as a conversion event. Target: 30+ submissions in first 30 days post-launch (current baseline: 0, since site has no booking function).

6. Timeline. Target launch: [specific date, ~8 weeks from contract signing]. Internal feedback turnaround: 48 hours on each phase. Phase expectation: Discovery 1 week, Design 2 weeks, Development 3 weeks, QA 1 week, Launch and handoff 1 week.

7. Budget range. ₱150,000–₱200,000 for project work. Hosting and ongoing maintenance separately budgeted, not part of this RFP.

8. Evaluation criteria.

• Approach and methodology: 30%
• Relevant experience (especially clinic, healthcare, or appointment-based businesses): 25%
• Price (line items required): 25%
• Timeline feasibility: 10%
• Communication fit: 10%

9. Submission instructions. Email PDF proposal (max 12 pages including portfolio examples) to [email] by [date], 5pm PHT. Required sections: approach, scope confirmation, team, similar work examples, timeline, line-item pricing, payment terms, questions/clarifications. Q&A: questions accepted via email through [date - 1 week]. Answers shared with all bidders within 48 hours.

10. Contact. [Name], [Role], [email]. Communication via email or contact form. SMS available for scheduling clarifications only — no voice calls.

---

That’s the whole RFP. Eight pages or so when formatted. Sufficient for a serious Business-tier project.

What I tell clients about RFP process

A few practical pieces of advice from running both sides of the table:

Send to 3–5 builders, not 10. Quality of bids drops when builders see you’ve shotgunned the RFP. The serious ones decline, sensing low close probability. You end up with proposals from builders who pursue volume.

Give 2 weeks minimum to respond. A serious proposal takes 4–8 hours of senior-builder time. Asking for it in 3 days filters for desperation, not quality.

Disclose your budget range. I cannot stress this enough. Without it, you get unusable quotes.

Run a Q&A round. Real questions from real builders surface things you didn’t think of. Sharing the answers with all bidders is fair and produces better proposals.

Read the whole proposal, not just the price. The cheapest bid is rarely the best value. The most expensive bid is rarely the best work. Read for evidence of understanding.

Decline politely. Builders who lost will pitch again later — keeping the relationship intact has option value. A two-line email (“Thanks for the proposal. We’ve selected another vendor whose approach was a closer fit. We appreciate the time you put in.”) is sufficient.

What I’d skip in an RFP

A few things I see in over-engineered RFPs that don’t add value for SMEs:

• Reference checks at proposal stage. Save these for shortlisted finalists.
• Detailed technical architecture diagrams. The builder’s approach explains this; you don’t need to spec it in advance.
• Mandatory in-person presentations. Async-first selection works fine for SMEs and respects builder time.
• Performance bonds or insurance certificates. These are enterprise procurement layers. SME projects don’t need them.
• Multi-page legal terms in the RFP itself. Save the contract for after selection.

Final thoughts on RFPs in PH

A good RFP doesn’t only get you better proposals — it gets you better builders. Serious senior solo operators and boutique shops respond to clear briefs because they save time on every step. They decline vague briefs because the project will be vague all the way through.

If you’re a PH SME running a real Business-tier project (₱120,000+) and you skip the RFP, you’re trading 6–10 hours of upfront writing for weeks of avoidable confusion later. Always wrong trade.

If you’ve drafted an RFP and want a written proposal in response — line-item pricing, milestone schedule, performance commitments — send me your project details and I’ll reply with a serious proposal within three Philippine business days.

---

Sources and notes:

• RFP structure reflects PH SME procurement practice and what serious builders actually respond to. Enterprise procurement RFPs (banks, BPOs, government) follow more rigid templates that aren’t appropriate for SME projects.

• Core Web Vitals thresholds (LCP < 2.5s, INP < 200ms, CLS < 0.1) reflect Google’s published “good” thresholds as of 2026; verify current thresholds on web.dev before locking targets.

• WCAG 2.1 AA is the practical accessibility standard for SME sites; full WCAG audits are enterprise scope.

• Hypothetical clinic example is illustrative; any resemblance to a real PH clinic is coincidental.

• Nothing here is legal, procurement, or compliance advice. For RFPs that trigger formal procurement regulations (government, listed corporations), consult a PH-licensed attorney.

• This article is not legal, tax, financial, or business-formation advice. For your specific situation, consult a Philippine-licensed accountant, lawyer, or BIR-accredited tax preparer.

• All pricing, fees, tax requirements, and platform features cited reflect publicly observable Philippine market data and the author’s research as of the publication date; verify current numbers with vendors and tax-authority sources before making decisions.

Related reading:

• Questions to ask before hiring a Philippine web designer
• How to vet a Filipino web designer in 30 minutes
• What a proper web design contract looks like in PH (template)
• How much does a website cost in the Philippines? (2026 guide)
• The complete guide to launching an e-commerce store in the Philippines

Frequently asked questions

Do I really need an RFP for a small Philippine web design project?

For projects under ₱50,000, no — a written brief and a one-page scope document are enough. For projects ₱120,000 and above (Business tier), yes. An RFP gets you comparable quotes from multiple builders, forces you to clarify your own requirements before talking to anyone, and dramatically improves negotiation leverage. Most PH SMEs skip the RFP and end up with three uncomparable quotes; that's a self-inflicted wound.

What's the difference between an RFP, RFQ, and RFI?

RFI (Request for Information) is exploratory — you're asking vendors to describe their capabilities and approach. RFQ (Request for Quote) assumes you know exactly what you want and just need pricing. RFP (Request for Proposal) sits between — you describe the problem and required outcomes, vendors propose how they'd solve it including price. For most PH SME web projects, an RFP is the right format because the solution isn't fixed yet.

How long should a PH web design RFP be?

5–8 pages of substance. Long enough to specify scope, deliverables, success metrics, timeline, budget range, and evaluation criteria. Short enough that builders actually read it. A 30-page enterprise RFP for a ₱200,000 SME project is overkill and signals to good builders that you'll be high-friction to work with. Most decline to bid.

Should I include a budget range in the RFP?

Yes, almost always. Builders quote against the budget range you signal — disclosing it gets you proposals scoped to your actual reality, not generic templates. Vendors who refuse to quote without your budget aren't doing it to gouge you (mostly); they need to know whether to propose a Starter, Business, or Premium-tier solution. Withholding the budget produces unusable quotes.

How many vendors should I send the RFP to?

Three to five. Fewer than three and you don't have a comparison. More than five and you waste your time evaluating and waste vendor time bidding. Most PH builders take 4–8 hours to write a serious proposal — sending to ten vendors creates ill will and you'll end up not reading half the responses anyway.

What success metrics should I require in a PH web design RFP?

Core Web Vitals (LCP under 2.5s, INP under 200ms, CLS under 0.1), mobile-first responsive layout, schema markup for the relevant page types, and at least one conversion-tied metric (form submissions, GCash checkouts, booking completions, whatever maps to your business goal). Don't require things you can't verify post-launch — vague language like 'best-in-class UX' is unenforceable.

Working with webdesigner.ph

• Service tiers — Start, Scale, Sell. What each tier includes and what it doesn't.
• Published pricing — Fixed price ranges per tier, named exclusions, and the payment schedule.
• How the process works — Discovery, design, build, and launch, with milestone-gated payment.
• Maintenance plans — Hosting, security, and content updates from ₱4,000/month.
• Get a specific quote — Reply within one Philippine business day.