This article is for anyone who needs to run a tender and choose an IT vendor for a website, mobile app, game localization project, or similar work. The recommendations will also be useful for vendors participating in tenders. You will learn the core principles of running IT tenders and avoiding common mistakes.

The framework in this article will help you run a tender successfully. You will learn how to identify genuinely capable specialists who can solve your problem on time and at a reasonable cost.

My view is simple: almost everything can be outsourced except decision-making.

All tables, images, and other files referenced in this article are available here: http://bit.ly/3G0I5H1.

What is Needed for a Successful Tender?

A successful tender is one in which you find a vendor who can solve your problem while meeting your quality, budget, and timeline requirements.

What do you need to do to achieve that?

• Agree within your team on who is responsible for what.
• Define the tender process and timeline.
• Set the proposal evaluation criteria and the basis for the final decision.
• Send a Request for Proposal (RFP) to vendors that includes:
  • A clear description of the task or problem.
  • An explanation of the working model and process.
  • Clear expectations regarding the outcome and vendor requirements.
  • A list of the documents you expect from the vendor, the questions they must answer, and the deadline for submitting the proposal.
• Invite vendors to participate in the tender.
• Communicate with them during the tender process.
• Summarize the results and make a decision.

Below, I explain each step in more detail. You will find practical tools, document templates, and processes that have proven effective in real projects.

Role Distribution

I recommend assigning the following roles:

• Customer - the person or team with the business need that the winning vendor must address.
• Manager - the person who runs the tender process.
• Tender Committee - the group that makes the final decision.

If necessary, one person can combine two or even all three roles. What matters is that every role is covered.

It is always better to have a single point of contact. One-to-one communication is more efficient than having vendors speak directly with the committee, the customer, and the manager at the same time. For the same reason, it is easier for the manager to work with one customer representative rather than with a whole group.

Who is Responsible for What within the Team?

To distribute responsibilities clearly, I recommend using a RACI matrix - a simple way to show who is responsible for what. The main goals of the RACI matrix are:

• To document the agreements inside the team.
• To identify areas that do not yet have an owner.

You can use the example below or create your own model, as long as everyone understands it and agrees to it from the start.

Important: Make sure each task or process has only one person marked as "A".

Example of distribution:

Timeline and Procedure for Conducting a Tender

Tender Procedure

This is a universal tender model. Use it as is or adapt it to your needs.

Tender Timelines

It is fairly easy to check whether your tender timeline is realistic. The table below shows the average timelines used by a large IT company. If your process is more complex or your stages take longer, this benchmark is still a useful reference point.

Request for Proposal

• RFI, Request for Information. The simplest type of request. It helps you learn about a company, its background, and its capabilities.
• RFQ, Request for Quotation. This request helps you understand the pricing and commercial terms used by companies in a given niche. A detailed task description is not required.
• RFP, Request for Proposal. This request includes a detailed description of the task and the desired working model. In response, vendors provide a concrete and comprehensive proposal.

RFP is the most comprehensive and demanding type of request, so that is what we will focus on here.

Your RFP should consist of the following items:

• Key information about the project.
• The working model and collaboration process, including operational communication, payment terms, guarantees, and similar topics.
• Key requirements for the vendor.
• Requirements for the vendor's proposal.
• Additional materials.

About the Project

Tender Timeline and Process

Specify when vendors must submit their proposals, how long you need to review them and make a decision, and who is authorized to communicate with vendors.

The Main Objectives of Your Project

The vendor must understand the real business outcome you want to achieve. For example, "build a corporate website as quickly as possible" and "build a corporate website that is easy to manage" are very different goals. Even though both can be described as "build a website," they lead to different proposals.

Project Timeline and Key Dates

When should the project start and finish? Which phases do you expect? What are the key dates for those phases? You may also want to ask the vendor for recommendations on milestone dates. This section should answer all of these questions.

Scope of Work

Briefly list the types of work and the responsibilities you expect from the vendor. "Build a website" is too vague. A much better approach is to describe the full scope, for example:

• Preparing and finalizing the technical specification.
• Designing the website and logo.
• Launching the website.
• Providing documentation or training on how to use the website.

Technical and Functional Requirements

Describe the desired outcome together with the technical and functional requirements, technologies, and constraints. In practice, this is your technical specification. It is one of the most important parts of the RFP: without a clear picture of the end result, you are unlikely to get the outcome you want. I recommend describing what problem needs to be solved and under what conditions, rather than prescribing every detail of how it must be done.

Write in a structured and concise way. Use numbering, reference the relevant sections of the technical specification, and explain your reasoning in areas that are complex, ambiguous, or likely to be debated.

Several examples of requirement descriptions:

About the Process of Collaboration

Communications

Describe how often you expect calls, which communication channels you use, and which time zone your team works in.

Change Management Procedure

Projects almost always change along the way. Explain how much change you expect, how you plan to handle it, and at which stages changes are likely to occur. Also clarify whether you want expected changes to be reflected in the budget from the start.

Work Acceptance Procedure and Timelines

Explain how you will accept the work, how long acceptance will take, and which criteria you will use to decide that the work has been completed properly.

Delivery Package

Define what you mean by a "delivery package." This may include not only the finished software, but also user manuals, source code, design source files, deployment materials, and so on. Make it clear that the contractor must be available to answer questions during acceptance, and that formal acceptance can start only after the full delivery package has been provided.

Payment

Describe the invoicing process and the payment triggers. I recommend linking payments to concrete milestones that produce meaningful results.

Do not tie payments to a vague "percentage of completion." That usually benefits the vendor more than the client.

Examples of Payment Triggers:

Vendor Requirements

Specify which vendor characteristics matter to you, for example:

• Availability of English-speaking specialists.
• A defined time zone corridor.
• Location.
• The ability to send employees on business trips.
• Relevant insurance coverage or certifications.

Proposal Requirements

What information do you expect from the vendor, and in what format should it be submitted?

I recommend asking for:

• A portfolio with similar projects.
• CVs or short professional profiles of the key people who may work on your project.
• The location of the team.
• A description of the risks the vendor sees and how they would manage them.
• A cost breakdown by work item.
• A list of the technologies the vendor plans to use, together with the reasoning behind those choices.

Risk Description

Ask vendors to describe the risks they see and how they would manage them. A strong vendor may immediately point out issues with the proposed technology stack and suggest better alternatives. They may also notice gaps such as missing GDPR requirements for personal data handling.

Cost Breakdown

A cost breakdown is a hierarchical list of the required tasks with an estimate for each one. In its simplest form, it looks like this:

Always ask for the cost breakdown in a format that helps you verify whether the vendor has understood the task correctly.

Examples:

• You may see a line item such as "Logo - 180 hours." If you are building a simple website for a niche wholesale business, that level of effort may be unnecessary, and this gives you something concrete to discuss.
• If the logo is missing from the cost breakdown even though it is clearly included in the RFP, the vendor may not have read the brief carefully.
• If the vendor provides two alternative estimates for the logo, that gives you a better basis for comparison and decision-making.

Additional Materials

Describe which additional files and materials you are providing and why they matter. It is usually best to share a link to a cloud folder so that documents can be updated easily if needed.

NDA

This section usually explains which documents must be exchanged and who is responsible for signing the NDA. Keep in mind that an NDA provides limited practical protection. In many cases, it is also a test of the vendor's legal flexibility and their genuine interest in your project.

Additionally

• Specify the units of measurement and the currency. For example, define whether pricing should be shown as an hourly rate in USD or as a total project cost in USD, and whether time should be measured in days or hours.
• Do not specify the evaluation criteria for proposals.
• Do not give vendors the opportunity to manipulate the results.
• Separate the sections of the RFP into appendices. This makes the documentation easier to understand, maintain, and reuse.

How to Evaluate Proposals?

Criteria and Their Priority Order

Define the proposal evaluation criteria and their priority order from the very beginning. This reduces the risk of manipulation and last-minute changes in priorities.

Evaluation of Proposals Based on Criteria

Define the exact number of points for each criterion, for example for "team experience." Without clear definitions, the evaluation becomes much less objective.

As a starting point, use the following framework:

• A universal list of evaluation questions.
• An evaluation matrix with scores and weights.

Download the framework here: Link.

Why Use 4 Points Instead of 5?

On a 5-point scale, 3 becomes the default choice whenever people are uncertain. On a 4-point scale, evaluators must choose either above or below average, which makes the assessment more decisive.

How to Evaluate Quantitative Metrics in Points?

Let us use proposal price as an example and divide it into four buckets with scores from 1 to 4. Suppose you receive five proposals:

• Proposal 1 – $120
• Proposal 2 – $30
• Proposal 3 – $150
• Proposal 4 – $90
• Proposal 5 – $70

Step 1. Define the Buckets and Their Boundaries

The higher the price, the fewer points should be assigned.

You can assign the buckets after you have received all proposals.

Step = (Maximum Amount – Minimum Amount) / Number of Buckets (points)

Step = (150 – 30) / 4 = 30

Step 2. Distribute Proposals into Buckets

Do not rush to work with the vendors at either extreme of the range - the cheapest and the most expensive proposals often reflect a misunderstanding of the task or an incomplete view of the risks. Focus on vendors who offer market-level pricing and realistic timelines.

Inviting Vendors to the Tender

I recommend inviting 8-12 vendors. With fewer than that, it is hard to understand the market properly. With more than that, communication overhead becomes too high.

What Should You Write in the Initial Email to a Vendor?

• Introduce yourself.
• Briefly explain why you are writing and what the tender is about.
• Concisely list the key dates for the tender and the project.
• Explain where they can find more detailed information.
• Ask whether they are interested in participating.
• Outline the next step for those who are interested.
• Optionally: if you cannot share project details immediately, explain the NDA process.

Example Email

Hello, Integral team,

My name is Dmitry Filatov, and I manage vendor selection at Roga i Kopyta. We are planning to launch a new corporate website and are looking for a vendor that can support the project end to end, including design, front-end development, and programming.

We are running a tender for this project and would like to invite you to participate. We came across your website and contact details through Google research.

The tender will run from February 23 through March 18. Between March 18 and March 25, we will review proposals, clarify details, and select the winning vendor. On March 26, we will inform all participants of the results.

The project is expected to start on March 28. You can find more information about the schedule, project scope, and proposal requirements here: [link].

Would you be interested in participating? If so, I would appreciate your reply within the next 2-3 days.

Where to Find Vendor Contacts?

In addition to Google searches and recommendations from colleagues, you can use http://vendors.dimafilatov.ru - my GameDev vendor catalog. It mainly includes small and mid-sized teams and offers convenient search, Excel export, and statistics.

Is it Possible to Work with Freelancers?

Yes, but not in every case. To understand whether your project is suitable for freelancers, answer a few questions, record the score for each answer, and calculate the total.

You can access the Freelance Meter here: Link.

Communication with Vendors During the Tender

Evaluate not only the proposals, but also the quality of the vendor's communication. How professional, clear, and thoughtful are they? Here are a few examples.

Positive Indicators:

• The vendor asks thoughtful questions that make you look at the project differently.
• After the conversation, the vendor sends a brief follow-up.
• The vendor uses quotations or clear formatting when replying to questions.
• The vendor identifies gaps in the brief and suggests ways to address them.
• The vendor submits the proposal within the established deadline.

Negative Indicators:

• The vendor asks many irrelevant questions that have already been answered in the RFP.
• They keep pushing for a call without clearly explaining why it is necessary.
• They communicate through a salesperson who cannot provide clear or accurate answers.

"Let's have a call!"

Do not agree to endless calls if everything is already described in the RFP. Instead, ask the vendor to collect their questions in writing and send them by email.

Knowledge Sharing Among Vendors

If one vendor asks an important question, share the answer with the other vendors as well to keep the process fair.

Tender Log

Keep a short log of your communication with each vendor - for example, "request sent," "questions received," or "response promised by the 27th." This helps you keep track of important details.

When communicating with vendors, copy one or two colleagues so the process can continue if you are unavailable.

Wrap-Up

What Should You Write to the Winner?

Do not rush to tell the vendor that they have definitively won the tender, as that can weaken your negotiating position. Instead, tell them they are among the finalists you would like to move forward with and propose a discussion of the commercial terms.

Short List and Plan B

Let the vendors who ranked second and third know that they were very close to winning, and ask whether they would be open to continuing the conversation if the preferred vendor does not sign the contract.

Notification to the Unsuccessful Vendors

Make sure you also write to the vendors who did not win. Leave a positive impression, explain the strengths of their proposal, point out the areas that could be improved, and ask whether they would be interested in taking part in future tenders.

Example Email:

Additional Recommendations for Conducting a Tender

If you run tenders regularly, design your documents so they can be reused with minimal effort.

Adjust your tender practices to fit the task at hand, and share lessons learned within the company so that your partner-selection process improves over time.

Acknowledgements

This material was not created by me alone. A large part of it is the result of work done by professionals in IT and procurement - my former and current colleagues from different companies. The biggest contributions came from Alexey Eynor, Dmitry Zenevich, Ekaterina Verbi, Vladimir Skrynko, Alexey Ugolkov, Sergey Berezhnoi, and Andrey Lankin.

Many thanks to those who assisted in preparing the material:

Sergey Evdokimov, Viktor Koroteev, Roman Zhikharev.