Internal IT Development. Limitations, Compromises, Insights

While working on a digitalization project, we created a single production management platform covering all the main processes (report collection, provision and assembly, personnel management, knowledge base and regulatory documents, etc.), we encountered one task that we would like to share in this article.

This is due to the fact that, after modeling six different options for the further development of our IT platform, we ultimately decided to bring the product to the external market instead of continuing to use it only within the customer company.

Where did this decision come from? The fact is that internal IT development almost inevitably encounters a number of systemic limitations, the impact of which does not diminish over time. And in this case, you need to think not about how to avoid them, but on the contrary, about how to work with them competently.

What are the benefits of in-house development?

The initial impetus for in-house development is clear. There are unique processes, specific conditions, limited budgets, and high sensitivity to information security. An in-house team adapts to the context faster, makes changes on the fly, and has a high degree of involvement overall. In our project, this allowed us to create a product that:

• digitalizes key business processes;

• reduces costs by tens of millions of rubles per year;

• scalable, integrated with 1C and works even with weak internet or on old infrastructure;

• improves control quality, efficiency and safety.

The other side of the coin

Any internal development inevitably encounters systemic limitations in the form of business processes, customer thinking and budget.

Let's consider each of them.

Business processes

A manufacturing company is not a startup. It has a different pace of change, a different management style, and much less flexibility in hiring and scaling. It is impossible to quickly expand or replace a team of developers: there are no mechanisms, no budget, no HR infrastructure for IT, and so on.

Customers from business

They are guided not by the best market practices, but by their narrow needs and vision. Their requirements often do not fit into the logic of the "product", violate the architecture, lead to fragmentation of solutions. In addition, they either have no IT experience, or it is very limited.

Budget

Internal products rarely receive stable, sufficient, and long-term funding. This leads to delays in development, revisions of priorities, and competition for budgets with other departments - all of which makes product development intermittent and vulnerable.

As a result, what was a flexible and fast solution yesterday turns into a cumbersome and vulnerable system in 2–3 years:

• the team is tired or has been reduced;

• the development turns out to be tied to just a couple of key employees who easily develop star fever;

• response speed decreases;

• business interest is cooling;

• the system becomes a "black box".

And what to do about it?

The first step is to recognize the inevitability of these limitations. Internal developments cannot and should not compete with IT companies in terms of speed, technology, and innovation. Their strength lies elsewhere: in a deep understanding of the context, in the ability to automate and integrate point-by-point, in control over infrastructure and security.

But to survive and be useful, a product must:

• have a clear development strategy and give up the desire to “do everything”;

• Share responsibility between business and IT - business should be involved not only as a consumer, but also as an investor and partner;

• have a modular architecture and documentation so as not to depend on specific people;

• be prepared to go beyond the company - as a business product or as an open solution to gain external resources and feedback.

In our case, the last point turned out to be a new vector of product development. And this is not a unique situation. Bringing your internal developments to the external market is a common trend. The problem here is that this is already a product with a strong specification for internal processes, which may not be needed on the external market. In addition, it is necessary to take into account that an IT product should not be sold as a basic service, but according to other principles, and the business may not be ready for this. For example, due to the narrow segment, there is a high risk of including all incurred costs in the price of one or two transactions, as a result we get an IT solution with a price tag of tens of millions for implementation and refinement.

It is important to understand that creating an internal IT product is a constant balance between unique advantages and systemic limitations. The sooner a company accepts this, the higher the chances that the IT product will not become another digital burden, but a sustainable growth tool. And it is best to move the team into a separate organization that will use the advantages of a flexible IT company and collect requests from the market. Then we do not get stuck in internal requests, but get expertise from the market and help our clients and internal customers to look wider and develop. In addition, we teach business discipline and project management, and not chaotic expression of wishes.