Develop Your Own or Buy Ready-Made: How to Avoid Making a Mistake in the Desire to Save Money

Now we are in the process of developing our own hardware transcoder and thus faced with a lot of difficult issues. The main question is what should be the price of such an integrated product, taking into account all the difficulties of its development and the cost of its maintenance?

We, as a vendor, try to make our products inexpensive, but most often, whatever price we charge, some customers may say: “it’s expensive, it’s cheaper to develop it ourselves.” This approach is a huge mistake and we will explain why.

Development and support of a complex product invariably grows due to staffing needs

The company’s internal developers provide themselves with lifelong employment. This is because it is impossible to develop a transcoder or streamer once and freeze a project by operating the created product unchanged. Protocols, playback devices, codecs, and other components are constantly changing. You need to constantly adapt to the requirements of the market.

We are well aware of the wide and rich capabilities of the open-source video processing software FFmpeg and GStreamer. Using these programs and scripting languages, it’s quite easy to make a proof of concept system that will transcode several programs with fixed parameters and even produce good quality streams using HLS output. The simplicity of creating product concepts often leads managers to make hasty decisions about starting internal development. Unfortunately, the next step is to begin to take into account the changing nature of video traffic. For example, broadcasters may switch the signal to local stations several times a day. The signal from regional and local stations may differ in picture resolution, the setting of GOP structures, used codecs, and such changes in signal settings will cause FFmpeg to freeze. This is just one example of what a qualified engineer involved in such a development should take into account.

So, the first and most important task is to hire a qualified engineer. To find them is not enough, you also need to give them work to do. After a year, it may suddenly turn out that there is no end to the FFmpeg tasks: the external conditions are changing, new input data is constantly being added. And then the vacation season begins, and, as a normal healthy person, our engineer will want to take a break. We can hope that on vacation they will be frantically coding with a laptop under the scorching sun, but they have every right to not do so.

Thus, a new task appears: to find another engineer who will relieve the main one. To manage these two engineers, we need a manager or even a team lead. By simple calculations, based only on the salaries of employees, our product using FFmpeg will cost us about $100,000. Not to mention the trifles of life as the cost of desktops, computers, and organizers for the office are simply lost in the background.

The inability to sell what was developed for the needs of the company

In the spring, a large-scale VK Fest was held - an online music festival that brought 40 million viewers together. We did not broadcast it, we did not provide the CDN, but it was our software that was chosen to ensure the delivery of the video streams. Why did the festival organizers not turn to the existing infrastructure? We don’t know the exact answer, but when a company prefers to turn to a third-party vendor, rather than take on an internal task of development, is very common and logical.

Since the infrastructure is internal, it solves only those tasks that arise specifically for a company. B2B vendors are involved in hundreds of diverse industries, and its variability is vast. This is what allows it to sell its product and pay back the cost of its development: it is used by a large number of customers with different tasks, each of which enriches a shared solution.

It’s very difficult to validate the relevance and profitability of internal infrastructure solutions teams. It is difficult for management to understand and assess how effectively the staff solves the tasks.

When developing an internal product, the focus is on basic functionality; user interfaces, usability, monitoring systems, documentation is left “for later” and almost never reaches a state where it can be sold to someone else or at least released as open-source. At the same time, some organizations are so deeply involved in the process of developing an internal product and spend so much time and money on this project that over time this system becomes fully operational, or at least covers the needs of the business. At this point, the amount of investment in the system is becoming so large that management may decide to try to sell it to someone. And the cycle of infusion of funds, now to bring the product to market, begins again.

A company that decides to spend significant resources on the internal development of atypical tools can easily find itself in a situation where there is simply no one to sell to. Consequently, an already expensive solution will simply be unbearable and a sad situation arises. The company is engaged in something else, but in its depths, there is a department that is too overfunded to just be disbanded and too underfunded to become financially independent.

Few companies dare to sell their internal product. So, you have an example like Amazon, which managed to become the world’s largest e-commerce platform and at the same time the creator and main supplier of cloud infrastructure. This happened precisely because they made their internal infrastructure available for use by others, allowing even other stores to launch sales on their servers. Doing this requires tremendous fortitude and cost.

“One solution for all” doesn’t equal “everyone’s the same”

So, we figured it out. But in addition to the high cost of the ready-made solution, customers also have other reasons in favor of not buying the ready-made and doing their own, namely: “If we buy from you, competitors will buy too, and everything will be the same for everyone.” If we are talking about a task such as transcoding (namely, this is what we are doing), then there is nothing wrong with the fact that everyone will have the same thing. In addition, there is always the possibility of a higher-level task setting and the development of an advanced solution for each individual customer to help them be ahead of their competitors.