How to use this template
Replace every [fill in] placeholder with your own information. Delete sections that don't apply. Keep the section numbering; vendors find it easier to map their proposal back to your RFP that way.
Most projects need 60 to 90 minutes of editing to make this template fit. The weighted vendor evaluation matrix in Section 8 is the part most teams rewrite; adjust the weightings so they reflect what actually matters to you, then leave them alone once the RFP goes out.
Cover page
Section 1: Project background and business context
[Your organization] is a [industry / sector] company headquartered in [city, country], operating since [year]. We [one sentence on what you do and who you serve].
This RFP covers [short description of the project; e.g. "the design and build of a new internal claims processing platform to replace our legacy system" or "the modernization of our customer portal from PHP to Node.js + React"].
The business context: [describe why this project matters now; e.g. "the current system was built in 2014 and is increasingly difficult to maintain", "we are expanding into 3 new markets and need internationalization", "we need to reduce per-transaction processing cost by 40%"].
The project will be sponsored by [name, role] and the day-to-day technical owner is [name, role]. Decisions will be made by [committee / individual].
Section 2: Goals and success criteria
By the end of this engagement we expect to have achieved the following measurable outcomes:
- Primary KPI: [e.g. "Reduce average page load from 12s to under 2s for the top 20 customer journeys"]
- Secondary KPI: [e.g. "Reduce monthly engineering maintenance hours from ~120 to under 40"]
- Business KPI: [e.g. "Enable launch in EU market within 6 months of go-live"]
- Quality KPI: [e.g. "Achieve 80%+ automated test coverage on all backend modules"]
- Operational KPI: [e.g. "Achieve 99.9% uptime SLA on the production environment for 90 days post go-live"]
Proposals will be evaluated in part on how directly they address these KPIs. Vendors should reference these KPIs explicitly in their proposed approach.
Section 3: Functional requirements (MoSCoW)
Requirements are prioritized using MoSCoW: Must (cannot launch without), Should (high value, planned for launch), Could (nice to have, may be deferred), Won't (out of scope for this engagement).
3.1 Must
- [e.g. "User registration with email + password + SSO via Google and Microsoft"]
- [e.g. "Role-based access control with 4 roles: admin, manager, agent, viewer"]
- [e.g. "Customer record CRUD with full audit trail"]
- [Add 5 to 15 must-have items here]
3.2 Should
- [e.g. "Bulk import from CSV with validation and rollback"]
- [e.g. "Scheduled report generation with email delivery"]
- [Add 5 to 10 should-have items here]
3.3 Could
- [e.g. "Native mobile app for iOS and Android"]
- [Add 3 to 5 could-have items here]
3.4 Won't (this engagement)
- [e.g. "Migration of historical data older than 5 years; will be archived separately"]
- [List explicit exclusions to prevent scope creep later]
Section 4: Non-functional requirements
| Category | Requirement | Target |
|---|---|---|
| Performance | p95 response time for primary user journeys | [e.g. <500ms server, <2s perceived] |
| Performance | Concurrent users supported on launch infrastructure | [e.g. 1,000 concurrent] |
| Scalability | Headroom to 10x concurrent without re-architecture | Required |
| Availability | Production uptime SLA | [e.g. 99.9%] |
| Availability | Disaster recovery RTO / RPO | [e.g. RTO 4h, RPO 1h] |
| Security | Encryption at rest | AES-256 minimum |
| Security | Encryption in transit | TLS 1.2 minimum, TLS 1.3 preferred |
| Security | Authentication | [e.g. OAuth 2.0 / OIDC, MFA on admin] |
| Security | Vulnerability scanning | Automated on every release |
| Compliance | Regulatory standards | [GDPR / HIPAA / PCI DSS / SOC 2 / ISO 27001] |
| Accessibility | Conformance level | [WCAG 2.2 AA] |
| Internationalization | Languages supported at launch | [List] |
| Internationalization | Currencies / timezones | [List] |
| Observability | Logging, metrics, tracing | Required across all services |
| Maintainability | Automated test coverage | [e.g. 80%+ for backend, 60%+ for frontend] |
| Documentation | API docs, runbook, ADRs | Required as deliverable |
Section 5: Technical constraints
5.1 Existing technology stack
Our current production environment uses: [list existing stack; e.g. "PHP 7.4 on Apache, MySQL 5.7, jQuery frontend, hosted on AWS EC2 instances in eu-west-1"].
5.2 Required integrations
- [e.g. "Stripe for payments; REST API"]
- [e.g. "Salesforce CRM; REST + webhook events"]
- [e.g. "Internal SSO via Okta SAML 2.0"]
- [List every external system that must integrate]
5.3 Data residency and hosting
Production data must be stored within [e.g. "the European Economic Area"]. Hosting provider must be one of [e.g. "AWS, GCP, or Azure"]. Cross-border data flows must be governed by [e.g. "Standard Contractual Clauses"].
5.4 Existing decisions and constraints
The following are non-negotiable: [list, e.g. "Database must remain PostgreSQL", "Authentication must use our existing Okta tenant", "Frontend must be a single-page application", or "None, open to recommendations"].
Section 6: Project timeline
The high-level milestones we are targeting:
| Milestone | Target date | Definition of done |
|---|---|---|
| Contract signed | [Date] | MSA + SOW countersigned |
| Discovery complete | [Date] | Architecture doc, sprint plan, written scope baseline |
| Sprint 1 demo | [Date] | End of first 2-week sprint |
| MVP feature complete | [Date] | All "Must" items passing acceptance tests |
| UAT start | [Date] | Staging environment ready for client testing |
| UAT sign-off | [Date] | Documented sign-off from project sponsor |
| Go-live | [Date] | Production cutover complete, monitoring green |
| Stabilization end | [Date] | 30 / 60 / 90 day post go-live milestone |
Vendor proposals should confirm whether these dates are achievable, flag risk areas, and propose an alternative timeline with reasoning if they cannot meet them.
Section 7: Budget envelope
Our budget envelope for this engagement is [e.g. "USD 150,000 to 220,000"], all-inclusive of discovery, build, QA, deployment, and 30 days of post go-live support.
Proposed payment structure: milestone-based, with the following anchor milestones:
- 10% on signature (mobilization)
- 20% on discovery complete + scope baseline signed
- 30% on MVP feature complete
- 20% on UAT sign-off
- 15% on go-live
- 5% on end of 30-day stabilization
Vendors may propose a different payment cadence with reasoning. We will not pay 100% upfront and we will not pay on time-and-materials alone for the initial build phase.
Section 8: Vendor evaluation criteria
Proposals will be scored against the following weighted criteria. Each criterion is scored 1 (poor) to 5 (excellent). The weighted total determines shortlist.
| Criterion | Weight | Score (1 to 5) | Weighted |
|---|---|---|---|
| Technical capability (stack fit, architecture, AI tooling adoption) | 25% | __ | __ |
| Process & methodology (sprint cadence, demo discipline, change-request protocol) | 20% | __ | __ |
| References & track record (similar projects, named references, employee tenure) | 20% | __ | __ |
| Cost & commercial (rate transparency, payment flexibility, exit terms) | 15% | __ | __ |
| Communication & culture fit (timezone overlap, written-update discipline, English fluency) | 10% | __ | __ |
| Security & compliance (encryption, GDPR/HIPAA posture, sub-processor list) | 10% | __ | __ |
| Total weighted score | 100% | -- | __/5.00 |
Section 9: Information requested from vendors
Please include the following in your response. Items marked "required" must be present for the proposal to be considered.
- Company information (required): legal entity name, country of registration, year founded, headcount, parent group (if any), key executives.
- Team CVs (required): anonymized CVs of the specific people who would be assigned to the engagement, including the named tech lead and senior engineer. We do not accept "best available at start date" proposals.
- Three references (required): contactable references from projects of similar scope and industry, completed within the last 24 months. We will contact at least two.
- Two case studies (required): written case studies covering the problem, approach, outcome, and measurable result. At least one must be in our industry.
- Sample architecture document: a sanitized architecture doc from a previous engagement (or describe what you would produce in discovery).
- Sample MSA: your standard Master Services Agreement, redacted as needed. Highlight clauses on IP ownership, data protection, SLA, and termination.
- Security questionnaire: completed responses to attached security questionnaire (or your equivalent; SIG Lite is acceptable).
- Pricing breakdown (required): itemized by phase (discovery, design, build, QA, deployment, post-launch support) with assumptions stated. Single line-item totals are not acceptable.
- Risk register: top 5 risks you see in our project as described, with proposed mitigations.
- Assumptions and exclusions: anything you have assumed in scoping, and anything you have explicitly excluded.
Section 10: RFP timeline
| Stage | Date | Notes |
|---|---|---|
| RFP issue date | [Date] | This document sent to invited vendors |
| Vendor Q&A window opens | [Date] | Questions to be sent in writing to primary contact |
| Q&A consolidated response | [Date] | All answers shared with all vendors |
| Q&A window closes | [Date] | No further questions after this date |
| Response deadline | [Date, time, timezone] | Proposals submitted via [method] |
| Shortlist announced | [Date] | Typically 2 to 3 vendors progress |
| Vendor calls / demos | [Date range] | 60 to 90 min per shortlisted vendor |
| Reference calls | [Date range] | 30 min per reference |
| Final decision | [Date] | All vendors notified within 5 business days |
| Target contract signature | [Date] | Contract negotiation typically 2 to 4 weeks |
Appendix A: Glossary
- MoSCoW: prioritization technique (Must, Should, Could, Won't).
- SOW: Statement of Work. The detailed scope document signed alongside the MSA.
- MSA: Master Services Agreement. The umbrella legal contract.
- NDA: Non-Disclosure Agreement.
- RTO: Recovery Time Objective. Maximum tolerable downtime after a disaster.
- RPO: Recovery Point Objective. Maximum tolerable data loss measured in time.
- SLA: Service Level Agreement.
- UAT: User Acceptance Testing.
- ADR: Architecture Decision Record. A short document capturing a significant architectural decision.
- p95: 95th percentile. The value below which 95% of requests fall.
Appendix B: NDA
By submitting a response to this RFP, the vendor acknowledges that all information contained in this document and any subsequent communication is confidential and may not be shared with third parties without written consent. Vendors may be asked to countersign a more detailed NDA prior to receiving access to additional materials (architecture diagrams, sample data, etc.).
A specimen NDA is available on request from the primary contact.