Should you build your own software development team?

There is practically no serious business that doesn’t rely on digital solutions. Nowadays, many companies use ready-made software available on the market. Nevertheless, along with the growth and specialization of business, there often appears the need to create dedicated software (you can read more about it in the article “Ten advantages of custom software”). Dedicated software can be ordered from a supplier or created by your own development team (if you have one).

Build your own dev team or look for a software development company?

Once the decision to create dedicated software has been made, the company faces a choice between involving an external company or hiring in-house developers.

Creating a programming department

Each of these approaches has advantages and disadvantages. In the first case, it is possible to choose between several models of cooperation (you can read more about it in the article “Cooperation models with a software development company”). In this article, we will focus on the second option – creating an in-house dev team.

Understanding the needs

Creating your own programming department may give your company a lot of benefits. The most obvious one is a good understanding of the needs. No one will understand the requirements and expectations of the company and employees better than a team member. An in-house developer can be a great solution because such a person works inside the company, has extensive knowledge about its internal processes, and simply knows who to ask.

On the other hand, your own dev team can sometimes have a slightly distorted perspective. Routine and attachment to common procedures in the company can have an impact on project decisions. Attachment to technologies is also a common thing. This is mainly because if the team members know and like them, they are eager to use them, even when those technologies aren’t an optimal solution for a given problem. This is one of the reasons why some companies hire external consultants who can objectively evaluate the quality and sense of the applied solutions.

The costs

An additional argument for building your own dev team is usually the cost of employment. If we assume that we, as well as a software development company, employ an employee for the identical market rate, it is obvious that the supplier must also add to the programmer's hourly rate his margin. Therefore, the cost per hour of an in-house developer will be significantly lower.

Nevertheless, the provider takes on other costs like recruitment, ensuring continuity of team’s work (e.g., replacements in case of illness), or administration. These costs can be difficult to estimate, as they are easily overlooked, but it is worth remembering about them in the overall calculation.

The risk

Unfortunately, employing a developer involves a number of risks. The biggest one is hiring a person with inadequate qualifications. The risk is particularly high in the case of the first IT specialist in the company – it is extremely difficult to verify the skills of the programmer if you do not have a trusted person with high technical competence. Even with the help of an experienced coder, it is still easy to make mistakes in this field (this will soon be described in detail in a separate article).

Since most companies start building a programming department by employing only one employee, the risk significantly increases. Moreover, other risk factors appear in one-person programming departments. Here are some that we have observed in our clients:

• insufficient competence to conduct large projects – a developer, who is good at small projects may not necessarily be able to deal with big systems;
• lack of continuity of work – when the developer isn’t available for a long period of time (for example because of an illness), the development of the project is halted;
• attachment to non-optimal technologies – the developer tends to use known and liked solutions and doesn’t always care about expanding their knowledge of new technologies;
• experimenting – the developer uses a company project to learn a new technology (often these are quite “exotic” technologies for which there are very little specialists available on the market);
• no control – basically no one in the company knows what the developer is doing and whether they’re doing it right or wrong;
• delegating the whole project to one person can become problematic when he or she leaves the company.

The last four points often lead to situations which we described in one of the previous articles, “IT Systems – unusual problems”.

Flexibility

Flexibility is one of the most important factors which decide about the successful or unsuccessful launch of software in your company. Usually working with your own dev team lets you achieve high flexibility – after all, the boss or management decides about the direction and scope of the programming work. They aren’t bound by any contract which would have to be renegotiated or even sometimes abandoned. However, at this point, it is worth mentioning that there is a chance for flexible cooperation in the case of a software development company (about which we wrote in the article “Cooperation models with a programming company”).

On the other hand, hiring a team is a long-term liability. Firing a company’s employee is never an easy or pleasant thing to do. It is much easier to terminate a contract with a supplier than with an employee, who is often very close to other team members. If you don’t have plans to constantly develop software in your company, it’s probably better to think about outsourcing.

Choosing the right technology for a project is another aspect of flexibility. As mentioned above, the dev team tends to prefer technologies known to them, which are not always best suited for the situation.

Involvement

However, if you decide to create your own dev team, it is worth knowing that it takes time and involvement to build a good team (this applies not only to programming). Selecting candidates, verifying their skills, training (both in used technology and in company procedures), team management, and solving current problems require a lot of work.

One- or two-person teams often work directly “under management”. But if the team is bigger, a trusted manager becomes essential to take the administrative part off the board, allowing them to focus on the strategic goals of the development department. Unfortunately, finding a good IT manager is even harder than finding a good developer.

We described the key characteristics of a project manager in the article "Three pillars of a good IT project manager".

Summary

When considering building a programming department in your company, you can expect that:

• the company’s needs will be well understood,
• the direct costs of employment will be lower,
• project management can be more flexible.

At the same time:

• there will be a number of risks associated with employing incompetent people,
• there will be less flexibility in the selection of technology,
• creating a team requires time and costs (of recruitment and administration),
• hiring employees is usually a bigger commitment than working with an external provider,
• at some point, a project manager will be needed

So, is it worth building your own dev team? It mainly depends on the company’s situation, the planned launch, and the future course of development. There isn’t one simple answer for everyone.

Nevertheless, when you have never managed a programming project, it is better to hand it over to a competent company. This way you can also learn valuable information about IT projects from the provider and later use it to build your own team if you want to.

It is also possible to try a “hybrid” approach and start by hiring an in-house manager who will supervise and direct the work of an external team. With a proven candidate for this position, this can be a good solution for the beginning. After all, even specialized software development companies sometimes use suppliers.

Finally, if we think that one developer will meet our needs, it is usually better to think about an external supplier in order to avoid administrative costs.