Writing a Request for Quotation for an IT Project
By CodexierPublished 7 min read
When three quotes for the same IT project differ by a factor of four, the suppliers are rarely the problem. The request was. Each supplier filled the gaps with their own assumptions, and you are now comparing three different projects. A good request for quotation (offertförfrågan) removes those gaps: it states the goal, the scope, the constraints and how you will choose, before anyone starts pricing. This guide gives you the structure, section by section, for a small or mid-sized company buying a website, app, integration or custom system.
Background and goals
Open with one page that a supplier can read in five minutes. Who you are, what the business does, what is not working today and what should be different after the project. Suppliers price risk, and an unclear purpose is the biggest risk they see, so a clear goal often lowers quotes on its own.
- Company and context: size, customers, how the affected process works today.
- The problem in business terms: "we lose enquiries because the booking flow breaks on mobile", not "we need a new website".
- The goal and how you will measure it: more bookings, fewer manual hours, a launch date tied to a season.
- Who the users are, and roughly how many.
- Who makes decisions on your side, and who will be the day-to-day contact.
Scope and requirements
Describe what the solution must do as user tasks rather than technical choices, and let suppliers propose how. "A customer can book and pay for a class on their phone and gets a confirmation by email" can be priced. "Modern, scalable booking system" cannot. Then sort every requirement into three groups, because that sorting is what makes quotes comparable.
| Group | What goes here | Example |
|---|---|---|
| Must-have | Without it the project has failed; every quote must include it | Booking with payment via Swish and card |
| Should-have | Valuable, priced separately so you can choose | Waiting list when a class is full |
| Out of scope | Explicitly excluded, so nobody prices it in | Member app, loyalty programme |
| Unknown | You are unsure; ask suppliers to propose and price options | Migration of old customer records |
Ask suppliers to price must-haves as one total and each should-have as a separate line. That single instruction does most of the work of making quotes comparable.
Our guide to writing a website requirements brief goes deeper on describing requirements for web projects; the same principles apply to apps and internal systems.
Constraints and must-haves
Constraints are the facts a supplier cannot change and must design around. Leaving them out is how you get a beautiful proposal that cannot be used. In Sweden the common ones are integrations with accounting and payments, login, accessibility and data protection.
- Systems it must work with: Fortnox or Visma, your CRM, payment providers such as Swish, Klarna or Stripe, BankID login.
- Legal requirements: GDPR and a data processing agreement, data stored in the EU/EEA, accessibility if you are covered by the accessibility rules, consumer rules for a webshop.
- Budget range. Giving one feels risky, but without it suppliers either guess high or propose something you cannot afford. A range lets them tell you what fits.
- Deadline and why: a hard date (season start, trade fair) is treated differently from a wish.
- Ownership and hosting: that you own the code and content, where it will run and who maintains it after launch.
- What you will provide: texts, images, access to systems, a person with time for testing.
Evaluation criteria decided in advance
Decide how you will choose before you read a single quote, and write it into the request. Otherwise the lowest price or the best presentation wins by default, and neither is the same as the best delivery. Publishing the criteria also tells suppliers what to put effort into.
| Criterion | Example weight | How to judge it |
|---|---|---|
| Understanding of the problem | High | Does the proposal restate your goal correctly and point out risks you missed? |
| Total cost over two years | High | Build price plus hosting, licences, maintenance and likely changes |
| Relevant experience | Medium | Comparable work you can look at, not logos |
| Delivery plan and your workload | Medium | Milestones, acceptance testing, what they need from you and when |
| After launch | Medium | Support terms, response times, what maintenance costs |
| Contract terms | Pass/fail | Ownership of code, data processing agreement, exit terms |
Weights are an example. Pick your own, but pick them before quotes arrive and do not change them afterwards.
If the quotes still differ widely, check which assumptions each supplier made about unknowns and whether they priced a fixed price or an estimate. Estimate, quote or fixed price explains the difference, and questions to ask a web agency helps in the follow-up meetings.
Timeline and questions process
A fair process gives every supplier the same information at the same time. That protects you as much as them: if one supplier learns something important in a phone call, their quote is no longer comparable.
- Send the request to three to five suppliers; more rarely improves the result and costs you evaluation time.
- Set a questions deadline about a week after sending.
- Answer all questions in one document shared with every supplier, without naming who asked.
- Give at least two weeks for quotes on anything beyond a small project; rushed quotes carry bigger safety margins.
- Shortlist two, meet them, and let them adjust for anything they misunderstood.
- Tell the suppliers you did not choose, briefly and with a reason. You may want to ask them again.
When you are not ready for an RFQ
An RFQ assumes you know what you want built. For a small, well-understood job, such as a standard company website, it is often overkill: compare two or three suppliers with published fixed prices, check their work and decide. For a new product or a system nobody has built for you before, the opposite problem appears: you cannot write the scope section honestly, and any fixed price you receive is a guess with a margin on top.
In that case, buy the planning first. Our MVP planning and architecture blueprint is a fixed-price phase that produces the scope, priorities, architecture and estimate that a good RFQ needs, and you are free to take the result to any supplier, including other agencies. Prices are on the pricing page. If you are unsure which situation you are in, book a call and we will tell you honestly whether you need a planning phase at all.
Frequently asked questions
How long should an RFQ for a small IT project be?
Often four to eight pages is enough: one page of background and goals, a couple of pages of scope sorted into must-have, should-have and out of scope, one page of constraints and one page on evaluation and timeline. Length is not the goal; removing ambiguity is.
Should we include our budget in the request?
Usually yes, as a range. It lets suppliers propose what fits instead of guessing, and it quickly filters out those who cannot deliver within it. Without a range you often get quotes that are either padded or impossible to afford.
Do private companies have to follow public procurement rules?
No. The Swedish public procurement rules (LOU) apply to public-sector buyers. A private company can run its process however it likes, but borrowing the basic principles of equal information and criteria set in advance makes the quotes far easier to compare.
Can we ask for a fixed price if the scope is uncertain?
You can, but you will pay for the uncertainty through margins, or later through change requests. It is usually better to fix the price of a first phase that removes the uncertainty and then ask for a fixed price for the rest.
Not sure your scope is ready to send out?
Show us your draft request or just describe the project. In 15 minutes we will point out the gaps suppliers will price as risk, and tell you whether a short planning phase would save you money.
Book a free 15-minute call