How to choose a contractor to develop a B2B portal, marketplace, and other complex software? Is it possible to compare IT companies by cost per hour? Many managers are concerned about how safe it is to choose a contractor with low prices. On the one hand, good things are expensive. And, having saved money, you can “buy” yourself a lot of problems. On the other hand, the budget is not rubber; resources are always limited (this is how business works). Where is the middle ground and the fair price?
My name is Andrey Putin and I am a managing partner at kt.team, an IT company with 20 years of experience in development. In this article, I'll explain why you shouldn't compare developers by cost per hour and choose an IT contractor based on a preliminary assessment of the terms of reference. The information will be useful to company executives, technical directors and other decision makers.
1. What determines the development price
The main factors are the cost, the availability of assumptions and additional work.
Cost
How much do developers make
There is a shortage of highly qualified specialists everywhere, and the IT labor market is no exception. This is where employers compete for employees. Salaries are rising, offices are getting cooler, non-financial motivation (which also costs money) is seen as a must have. This is the situation everywhere: we have offices in three cities (Moscow, Krasnodar, Togliatti), and salaries are balanced everywhere: their median values differ by no more than 30%. None of the three cities can be called “cheap”.
A developer's salary depends on his skills, technical level, experience, and specialization (stack). The average salary in the IT sector in the second half of 2019 was 113,313 rubles per month. A software architect, for example, earns an average of 190,000 rubles a month, and a front-end developer — 100,000 rubles.
Yes, we know rare stories about IT companies where developers are paid 30,000 rubles a month. It always ends the same way: a huge turnover.
{{cta}}
The cost of the developer's job
In addition to salaries, the price for the services of an IT specialist includes:
- expensive equipment;
- staff overhead costs (office, employee service — food, health insurance and much more);
- taxes;
- overhead costs for business processes (accounting, management, security, automation services, etc.).
Let's imagine that the cost of providing for one employee is 100,000 rubles per month (let's take a below-market salary and minimum taxes). If you divide this amount by the number of working hours per month (and there are about 140 of them, including lunches), then the cost of an hour can no longer be lower than 714 rubles.
If your team consists of architects and seniors, then, taking into account taxes and an inexpensive team manager, the lowest cost will be around 250,000 rubles a month. This is just over 1,785 rubles per hour. Add at least insignificant infrastructure costs (at least 10%) — it already turns out to be 1,964 rubles per hour. If you find a price lower than these values, you can be sure that either there are nuances about the team's level, or there will be multipliers in the hours shown.
Presence of assumptions
If companies are cost-balanced, does it mean that it is possible to send a technical specification to the customer and compare the number of hours? What if one team does it faster than the other? Here you will find another nuance.
A difference in valuation by several times hardly means that contractors rated the same thing. Most likely, you see different approaches to implementing your wishes with different risk assumptions.
The customer expects this to be a price for the same amount of work and the same performance. But in fact, this is a choice between implementing A and implementing B. They differ:
- scope of work — as the result of completing the task, we consider the strict implementation of what has been read or we take into account the necessary adjustments during the work process;
- the number of risks taken into account;
- the presence (and, in the vast majority, the absence) of unit, integration, and API functional tests.
Additional works
Unlike the cost, which is approximately the same for all contractors, the list of additional works they offer can vary significantly. For example, development with automated testing will cost more than without it. Autotests improve the development culture, but at the same time they take more time and, accordingly, increase the check.
At the same time, the customer, of course, has the right to refuse to cover the code with autotests. This is everyone's choice: what condition should the project be in a year's time? Is it acceptable for a client-side team to constantly spend significant time fixing bugs due to the rejection of best practices for preventing regression?
2. How do you compare prices when choosing a contractor?
It is incorrect to estimate development costs in absolute terms. Let's take an example of why.
Do you think that five million rubles for developing an e-commerce project is expensive? In the abstract, five million is an impressive sum. Other data may also be known:
- we are talking about an online store that generates 20% of all customers to the chain's offline stores with an annual revenue of 40 billion rubles;
- The online store's own annual turnover is more than three billion rubles.
Five million doesn't seem like a big sum anymore, because 0.04% conversion growth pays off the entire project in a month.
Yes, you can save on development. And a manager can choose a contractor who offers a lower price. But others will need to brag about — not about the budget, but about the success of the project.
3. Development profitability
The most important thing in discussing a project is profitability. We often see that there is no link between profitability and investment. It's not the price of development that matters, but how quickly the result pays off and starts making a profit.
In other words, a development product is an asset (generating money), but its value is considered as the value of a liability (consuming money). Yes, the development product is intangible, but we can compare it to a machine in production. It doesn't matter how much the machine cost the plant if it pays off and runs smoothly, right? And would it be a shame if a cheap machine doesn't do its job, slows down the conveyor, stays idle, and needs repairs forever?
The cost of development and the depth of development and planning should be balanced by the potential of the software product and its ROI (return on investment).
It is very important to define goals and metrics — not technical ones, but business ones — and review them along with improving the product. And in order to be able to review them quickly, a certain flexibility in approach is required. With a flexible approach, it is reasonable to spend on IT in the same place where the value from IT is in every sprint.
4. Speaking of technical specifications
In fact, development according to technical specifications is unprofitable and inconvenient. It's hard to write, it's hard to accept work on, and many requirements change in the process.
Both government officials and large bureaucratic clients — everything changes for everyone. We already have a dozen major projects that were launched in a state that was very different from the technical specifications!
My colleague Jacklyn Buffo wrote in detail about technical specifications in IT in another article —”MVP, or how not to get into endless development”. There are also interesting cases there, an example is quoted below.
“The creation of a technical specification is a year long.
Our regular customer department asked us to make a fixsprice volume. Like, the requirements are clear, the functionality is simple, we'll draw the mockups ourselves, just do it. It was possible to collect technical specifications for “understandable” requirements and sign an agreement for them only a year later (!) , because the customer has a job to do, in addition to agreeing on technical specifications, it is difficult and time-consuming to read a large document — while you are discussing one part of the document, you forget the other part, after a while you need to edit previously written parts, etc.
As a result, after two months of development, one of the functional customers leaves, and the “clear and simple” requirements became so complex after clarification that even the customer began to get lost in the calculation methodology that he himself proposed.”
After such cases, it becomes clear that a strict technical specification only gives the illusion of control. Assessing such a specification by fixspice does not make sense.
It is not surprising that commercial proposals prepared according to such specifications may contain assumptions about timing and quality.
Some contractors do not take into account actual problems (they underestimate risks). Others, on the contrary, like to “let them fear” and take into account difficulties that do not exist. When conducting a tender, each contractor will think: “Do I need to make a checkpoint based on the technical specifications or should I rethink it down or up?”
5. Final criteria for selecting an IT contractor
It is important for a development customer that the team is his asset, not a liability. Since good developers are always expensive, it's best not to focus on saving money. The focus should be on planning business goals to ensure a return on investment.
But in order to choose an IT company objectively, pay a fair price and not be deceived, it is useful to know how the pricing for the services you need is structured.
Signs of a fair price for IT contractor services
1 Transparency in hour logging and billing
The contractor must provide you with all their calculations. You should have access to each employee's performance reports at all times to know what the time you're paying for was spent on.
2 Development culture
When an IT company develops a development culture and uses test-driven development, or a microservice approach, it spends less time debugging, code refactoring, and other unproductive losses. In the future, this is beneficial for the customer: the project will not get bogged down in bug fixes.
A high development culture and an in-house team also mean that the team is interested in improving all production processes.
3 Team transparency
The contractor should show you the whole team (at least introduce them in general chats) so that there are no “dead souls” on the project. The number and qualifications of developers must match what you'll see on your invoices.
You can learn more about the price of development services in our company and see price examples for abstract projects on the page”The basics of our pricing”. This will help you better understand the specifics of IT pricing.
Choose contractors not by cost per hour or by the assessment of your technical specifications, but by their ability to provide a quick return on your investment.
{{cta}}
.avif)
