Document generators
IT request for proposal generator — comparable offers instead of chaos
A specification says what should be built. A request for proposal says how you will choose a vendor - and that is what decides whether the offers can be compared at all. Without stated criteria and weights every vendor optimises for price, because it is the only thing they can see. This generator assembles the document that fixes that.
Free · no signup · runs in your browser
1. Buyer and subject
Industry and scale. The name can wait until an NDA is signed.
In one sentence: what is to be built.
How you will know the project succeeded. Measurable if possible.
2. Scope of the request
Main areas. Functional detail is best attached as a separate brief.
What the vendor should explicitly leave out of the quote.
Systems, mandated technologies, hosting constraints.
3. Selection criteria
E.g. price, industry experience, timeline, way of working, quality of communication.
Give weights and you get comparable proposals. Without them, everyone optimises for price.
4. Budget and schedule
E.g. stages with acceptance, payment per stage.
5. Terms of engagement
Transfer of economic copyright or a licence - both are normal, but it must be settled before starting.
6. Process
By when and in what form vendors can ask for clarification.
Request preview
# Request for proposal - IT project ## 1. Buyer and subject **Who the buyer is** _to be agreed_ **Subject of the request** _to be agreed_ **Business goal** _to be agreed_ ## 2. Scope of the request **Scope covered by the proposal** _to be agreed_ **Out of scope** _to be agreed_ **Required integrations and environment** _to be agreed_ ## 3. Selection criteria **Proposal evaluation criteria** _to be agreed_ **Criteria weights** _to be agreed_ **Required references or experience** _to be agreed_ ## 4. Budget and schedule **Budget range** _to be agreed_ **Expected delivery timeline** _to be agreed_ **Milestones and payment structure** _to be agreed_ ## 5. Terms of engagement **Contract model** _to be agreed_ **Rights to the code** _to be agreed_ **Expected warranty and post-launch support** _to be agreed_ ## 6. Process **Proposal submission deadline** _to be agreed_ **Contact person** _to be agreed_ **How to ask questions** _to be agreed_ ## Open points The points below are not settled yet. Please address them in your proposal or raise a question through the stated channel. - Who the buyer is - Subject of the request - Business goal - Scope covered by the proposal - Out of scope - Required integrations and environment - Proposal evaluation criteria - Criteria weights - Required references or experience - Budget range - Expected delivery timeline - Milestones and payment structure - Contract model - Rights to the code - Expected warranty and post-launch support - Proposal submission deadline - Contact person - How to ask questions --- _Document generated with a free tool by Exmoor Software (exmoor.pl/en/tools). The content belongs entirely to the buyer._
Want us to respond to this request?
Get a ballpark instantly in our quote calculator. A human replies to your first message within 24 hours, and we prepare a firm quote after a short call about scope.
Estimate your project in 2 minHow it works
- 01
Describe the process
Who is asking, for what, in what scope, and what is explicitly outside the proposal.
- 02
State criteria and weights
The most important section. If price should weigh 40% and industry experience 30%, say so - you will get proposals shaped around those criteria.
- 03
Set terms and process
Payment model, rights to the code, warranty, submission deadline and how to ask questions. You download a ready .md file.
Assumptions and limits
- This document is not a contract template or a public procurement document. It is a commercial request for a private process.
- Functional scope is best attached as a separate brief - that is what our spec generator is for. Splitting "what we build" from "how we choose" makes life easier for both sides.
- Rights to the code: transfer of economic copyright and a licence are two different, entirely normal models. What matters is choosing deliberately before starting, because changing later can be expensive.
- Stating a budget range shortens the process. The fear that "vendors will inflate to the budget" is usually a smaller problem than three proposals differing tenfold because everyone guessed differently.
- The document is produced entirely in your browser - we never see its content.
Frequently asked questions
Do I have to state a budget? +
You do not have to, but it helps. Without a range vendors guess, and proposals can differ by an order of magnitude - not because anyone is inflating, but because each assumed a different scope.
How is this different from the spec generator? +
A specification describes the product: problem, users, features, integrations. A request for proposal describes the process: criteria, weights, contract terms, deadlines. Best sent together.
How many companies should I invite? +
Three is usually a sensible compromise: enough to compare approaches, few enough to talk to each properly. With ten proposals, evaluation takes more time than the choice is worth.
Can I send this request to you as well? +
Of course. You get a ballpark instantly in our quote calculator, a reply from a human within 24 hours, and a firm quote after a short call.
Related tools
All tools →Spec generator
Answer a dozen questions and download a ready Markdown brief that every vendor will read the same way.
User story generator
Turn a wish list into prioritised stories with acceptance criteria that can actually be costed.
Custom vs SaaS
Compare the total cost of ownership of an off-the-shelf subscription and a custom build over 3 and 5 years.
Turn the numbers into a project
Get a ballpark instantly, a reply from a human within 24 hours and a firm quote after a short call. No obligation.
Estimate your project in 2 min