Institutional website RFP: complete 2026 template (ministry, NGO, city hall)

Institutional sites — ministries, city halls, public agencies, NGOs — share one difficulty: a vague RFP produces non-comparable bids and slipping deliveries. This template structures your RFP to attract serious proposals and projects that ship.

TL;DR

- 12 mandatory sections: context, goals, functional scope, technical, accessibility, security, content, maintenance, planning, deliverables, criteria, budget.

- Template used on 4 institutional RFPs in Africa (SN, CI, BJ, CM) — average selection time: 21 days.

- Bad RFP = bid spread 1 to 5× across vendors on the SAME project.

Section 1 — Institution context

`

1.1 Institution overview

• Mission, key missions
• Supervisory body
• Target audience (citizens, partners, media)
• Current: existing URL, monthly traffic, online services

1.2 Why a new site

• Redesign (obsolete) or initial creation
• Triggers: governance change, new services, accessibility compliance, etc.

1.3 Political / institutional constraints

• Mandatory official colors / logo
• National hosting required or not
• Sensitive data (civil registry, health, justice, etc.)

`

Section 2 — Measurable goals

`

At 12 months post-launch:

• Monthly visits: from X to Y
• Online services completed: Z per month
• WCAG accessibility rate: 95%+ AA level
• Lighthouse Performance: 90+
• Home page 3G load: <2s
• Availability: 99.9% SLA
• Languages: FR + EN + Wolof / Bambara / Lingala / etc.

`

Section 3 — Functional scope

List all features, marked MUST / SHOULD / COULD:

`

PUBLIC

[MUST] Multilingual home

[MUST] Institution pages (org chart, missions, leadership)

[MUST] News / press releases (CMS)

[MUST] Service directory

[MUST] Staff directory + agents (with search)

[MUST] Public document downloads (reports, laws, decrees)

[SHOULD] Event calendar + RSS

[SHOULD] Media gallery (photo, video, audio)

[SHOULD] Newsletter (opt-in)

[COULD] Citizen portal (case tracking)

[COULD] FAQ chatbot

ADMIN

[MUST] CMS for editors (multilingual, validation workflow)

[MUST] Media management

[MUST] Internal user management (roles: editor, validator, admin)

[MUST] Audit logs

[SHOULD] Multi-level publication workflow

[COULD] Built-in stats (internal dashboard)

`

Section 4 — Technical scope

`

4.1 Acceptable stack

• Frontend: Next.js, Astro, or equivalent SSG/SSR
• Backend: Node.js, Python, or PHP (Laravel/Symfony)
• DB: PostgreSQL (relational) or MongoDB (justify)
• CMS: Strapi, Payload, Sanity, or custom (justify)

4.2 Hosting

• National (sensitive institutional): ADIE Senegal, ADIE Ivory Coast, ANTIC Cameroon
• Or international with sovereignty guarantees (EU, USA — SCCs)
• HTTPS mandatory (Let's Encrypt acceptable)
• CDN: Cloudflare or equivalent

4.3 Performance

• Home 3G: <2s
• Secondary pages 3G: <3s
• Lighthouse Mobile Performance: ≥90
• Lighthouse Accessibility: ≥95
• Lighthouse Best Practices: ≥95
• Lighthouse SEO: ≥95

4.4 Browser compatibility

• Chrome / Firefox / Safari (last 3 versions)
• Current Edge
• Samsung Internet (Africa mobile)
• Opera Mini (Africa low-end)

`

Section 5 — Accessibility (RGAA / WCAG 2.2)

`

5.1 Compliance target

• WCAG 2.2 AA (95% minimum)
• RGAA 4.1 (France) if francophone dependency
• Tests: axe-core CI + manual audit by certified expert

5.2 Specific requirements

• Alt text on 100% of images
• Captions on 100% of videos
• Transcripts on 100% of audio
• Full keyboard navigation
• AAA contrast on main text
• Dyslexia-friendly fonts (Atkinson Hyperlegible or OpenDyslexic optional)
• High contrast mode (user toggle)

`

See accessibility RGAA WCAG 2.2 administration →.

Section 6 — Security

`

6.1 Admin auth

• MFA mandatory (TOTP minimum, FIDO2/WebAuthn preferred)
• 30-min session timeout
• Password policy: 14+ chars, 90-day rotation

6.2 Data

• TLS encryption everywhere (HSTS preload)
• Sensitive data encrypted at-rest
• Daily + monthly encrypted backups, 5-year retention
• Audit logs kept 5+ years

6.3 Security tests

• Pentest before delivery + annual
• Source code audit by third party (public contract >50M XOF)
• Optional bug bounty

`

Section 7 — Content & SEO

`

7.1 Content migration

• Existing site: X pages, Y PDFs
• Migration plan: crawl + cleanup + re-import
• Mandatory 301 redirects (preserve SEO)
• Critical URL list provided in annex

7.2 Base SEO

• Meta title + description per page
• Schema.org Government / NGO per case
• XML sitemap + robots.txt
• Multilingual hreflang

`

Section 8 — Planning & deliverables

`

8.1 Phases

Phase 1 (Wk 1-3): existing audit, design system, Figma mocks

Phase 2 (Wk 4-7): front + back development, CMS

Phase 3 (Wk 8-10): content migration, integration, tests

Phase 4 (Wk 11-12): client UAT, accessibility, prod launch

Phase 5 (Wk 13+): maintenance/support

8.2 Deliverables

• High-fidelity Figma mocks
• Complete source code (Git, client property)
• Tech + user docs
• Deploy + rollback procedures
• CMS manual (editors)
• UAT minutes
• Signed Lighthouse + WCAG audits

`

Section 9 — Selection criteria

`

9.1 Recommended weights

• Demonstrated technical skill: 35%
• Need understanding: 20%
• Methodological approach: 15%
• Similar references: 15%
• Price: 10%
• Timeline: 5%

9.2 Required documents

• Project methodology
• Assigned team (CVs)
• 3 similar project references (with contacts)
• Detailed quote
• Forecast schedule
• Legal terms

`

Section 10 — Budget & payment

`

10.1 Envelope

State range: 15-50M XOF for medium institutional site.

10.2 Payment

• 30% on order
• 30% on mockup approval
• 30% on delivery
• 10% at 3-month post-launch (warranty)

`

Section 11 — Maintenance

`

11.1 12-month minimum support

• Bug fixes: 48h critical, 5 days minor
• Security updates: 24h critical
• Minor evolutions: 5 person-days included/month
• Availability SLA: 99.9%

11.2 On-call

• 9-18 local hotline support
• After-hours on-call: optional, quoted

`

Section 12 — Legal

`

• IP: full transfer to institution
• Source code: delivered each milestone, in client Git
• Confidentiality: NDA signed at start
• Warranty: 12 months on delivery
• GDPR / Law 2008-12: documented compliance

`

Real case — Education Ministry RFP (anonymized)

Well-framed RFP → 7 bids received, 5 compliant, bid spread 22-38M XOF.

Vague RFP → 11 bids received, 4 off-topic, spread 12-78M XOF, selection blocked 90 days.

A good RFP saves time for EVERYONE (writer + bidders + selectors).

FAQ

Q: Public tender or simplified procurement?

A: In Senegal, public tender mandatory past 25M XOF. Public procurement code applies. Sites <25M: simplified procurement.

Q: Open source in institutions?

A: Recommended. Public code remains auditable, reusable. Mature options: Strapi, Payload, Plone, Drupal.

Q: National hosting or international cloud?

A: For non-sensitive data, international cloud OK (Vercel, Cloudflare). Sensitive data or sovereignty: mandatory national hosting (ADIE SN).

Conclusion

A solid institutional RFP fits in 15-25 well-written pages. No more. The trap: copying "modern" private-sector RFPs that skip accessibility, security, archiving. This template is to adapt to your context, but its structure is proven on 4 real African Francophone RFPs.