How to write an effective software development quote

Greetings! I am Danil Vilkhovsky, CEO of a custom software development company.

We often receive requests to calculate the cost of a project. Some RFQs are real masterpieces: they are detailed, well structured. Others, say, require a lot of clarification. And this gave me the idea that it would be nice to create a small guide to compiling a unified and therefore effective request for a price.

Conclusion: an effective RFQ can significantly save the customer's time and even speed up the start of the project — Conclusion: an effective RFQ can significantly save the customer’s time and even speed up the start of the project

So, the initial situation: there is a project to develop software, such as a CRM system.

It is necessary: to send out requests for calculating the cost of the project to several IT companies and / or put the project up for tender.

Task: compose an effective request for quotation (RFQ, request for quotation).

Why it’s Important to Prepare an Effective Quote

The request for quotation is an important document. In fact, it is an invitation to participate in the tender.

It should be noted that this document is needed not only by large companies with formalized tender selection business processes and cost as the main decisive factor, but also by representatives of small and medium-sized businesses. And it is necessary even when you enter a freelance platform with a project.

Effective RFQ achieves two goals at the same time:

First, it provides software companies with a clear understanding of your needs and requirements, both in terms of the required solution and in terms of partnership conditions. At the same time, significantly reducing the number and time of communications aimed at clarifying the requirements for the project.
Secondly, it is for you, as a customer, a tool for obtaining correct price reference points, their correct comparison, as well as filtering unsuitable contractors.

What sections to include in an RFQ

Like any formalized document, a request for quotation has its own structure. This allows you to organize information in the most readable way, as well as use templates, adapting them to your project.

Introduction

The purpose of this section is to provide a brief overview of your organization, its business environment, and the challenges that need to be overcome. One of the important points here is the indication of the industry in which your organization operates.

In general, this directly raises the question of the industry specialization of an IT company and the possibility of its compliance with the formal requirements of the industry itself (for example, requirements for security, data encryption, etc. differ significantly in the banking sector and, for example, in the field of production furniture)

General characteristics of the project

Here you need to provide a brief description of what software you need.

For example, if you need a CRM system, then this section is the right place to be specific. The goals of the project and end users should also be mentioned as important points.

Detailed description of the project

In this section, it is necessary to describe the required functionality of the product. In other words, here you provide user stories for later implementation.

For example, for a CRM system, you can start with user stories such as conversations with customers, correspondence (including within the organization), notifications, and user interactions. Each of these functions should then be expanded so that developers have a complete understanding of what should be the input and output of each.

Project Scope and Expected Results

Here you define the MVP, the minimum viable product that you expect to receive, and also prioritize tasks.

For example, when processing a request for a price for the development of a CRM system, you can specify that you first need to create correspondence tools, then notification tools, then monitoring functions, and so on.

In addition, when working through this section, it would be a good idea to make an internal estimate of the volumes in order to subsequently have some basis for comparison.

Required technology stack

In this section, you should indicate which technologies should be involved in the project. The required technology stack may include programming languages and frameworks (both for the development of the server and client parts), libraries, databases, cloud services, if necessary.

For example, if the back-end implementation must be exclusively in Python, specify that aspect in this section. If you see your product based on a MySQL database, please indicate that as well.

quality requirements

Here you should touch on both the functional and non-functional aspects of the developed solution that needs to be obtained. For example, these may be security requirements, user data privacy, program performance, expected loads, etc. Ideally, identify indicators that can be used to assess the degree of fulfillment of product quality requirements.

For example, it can be prioritization of vulnerabilities, determining the recovery time of the program in case of DDoS attacks.

Main stages and terms of the project

Here you should indicate the expected time frame for creating the MVP, benchmarks for iterations. In this way, you will help IT companies understand your expectations and determine whether they can meet them.

For example, you can set deadlines as an exact date or a specific period in a project’s pipeline. And also indicate the expected duration of sprints, etc.

General terms and conditions

Here you need to disclose your expectations regarding the pricing model within which you plan to cooperate on this project, requirements for the protection of intellectual property, and other conditions.

For example, if you are targeting a contract based on a fixed price, you can specify a target budget for the project. If you’re going to use a time-based pricing model, you can specify a maximum allowable hourly rate. If one of the conditions for cooperation is the signing of a non-disclosure agreement, also indicate this in this section of the request for proposals template. If it’s important to you that developers submit results to GitHub, please also indicate this here. If there is a value in which time zone the developers should be, this point can also be voiced in this section.

The contact person

Here you should indicate the person responsible for communication in the framework of the ongoing request for quotations / tender. Those. directly to whom contractors can contact as part of the discussion of the details of the project. Also here you should indicate the contacts and the preferred method of communication.

For example, if you are submitting an RFQ through a feedback form on a software company’s website, include not only an email address where they can send their request, but also a phone number they can contact for clarifications and clarifications, and also position, name and patronymic of the contact person.

Pricing Template

On the one hand, this section is not critical in terms of providing information on the project. However, it can be included in the RFQ as an annex in order to unify the structure of incoming proposals. In other words, using a unified template can help you further simplify the process of comparing offers.

For example, a pricing template might include a table with columns such as tasks, amount of work in man-hours, hourly rate, maximum number of man-hours per day/week, and so on.

Pre-qualification requirements

Here you set out your conditions regarding the general competence and expertise that an IT company must meet in order for you to even begin to consider its proposal. Naturally, if such conditions exist.

For example, if it is important for you that the applicant company has at least one successfully completed project in the target domain, this section is perfect for voicing this aspect. If the duration of the project is important (for example, developers should have at least six months of project management experience), this should also be indicated in this section. In addition, if it is critical, you can make a reservation here about the admission (or non-admission) of the appointment to work on your project.

In this case, of course, one should remember about the adequacy of the requirements. For example, banning junior developers from participating in your project is unlikely to be appropriate if the targeted hourly rate specified in the General Terms and Conditions section is at the lower end of the price range in the market as a whole.

Application deadlines

In this section, you can specify the date until which applications will be accepted. It is important that the terms, on the one hand, be reasonably limited (you cannot collect applications for months). On the other hand, they are quite long, i.e. enough for the developers to correctly assess the volumes and suitable solutions (you don’t need hastily drafted applications, in which there are many unaccounted aspects, etc.).

For example, for a small project worth less than 1 million rubles, a suitable period for collecting applications is one to one and a half weeks. For tender procedures in large, vertically structured organizations, and larger projects, the terms are usually higher and can reach a month or more.

In conclusion, a well-prepared RFQ will not only save time spent discussing the project, but will also help you get more detailed proposals, as well as make it easier to directly choose the company to which you entrust your project.