Subscription Instead of Projects: Why the IT Systems Implementation Market Is Changing — and How We at Business Lab Came to This Model Ourselves

A clear trend is becoming more visible in the IT systems implementation market: companies are buying “turnkey projects” less and less often and increasingly choosing an ongoing support model instead. This applies to CRM, sales automation, financial accounting, customer service, and, more broadly, to any systems that must not only be implemented but must also work effectively in day-to-day operations.

At Business Lab, we did not move to a subscription model because it was fashionable. On the contrary, the trend became obvious precisely because the market as a whole ran into the same issues we had been seeing for years in our work with clients.

For Dmitrii Solovev, Business Lab’s co-founder and COO, this shift was not a theoretical conclusion but the result of many years of practical experience. Working at the intersection of business processes, operations management, and systems implementation, he repeatedly saw companies trying to solve dynamic, evolving challenges through a static project-based approach — and almost always running into the limitations of that model.

For a long time, the one-off project model seemed logical. A company would come with a request, define the task, the integrator would estimate the scope of work, the parties would agree on deadlines and budget, and then implementation would begin. On paper, everything looked clear: there was a start, a scope, and a final result.

But in real life, things do not work that linearly.

In practice, most companies, especially in the small and medium-sized business segment, do not come with a finished technical specification. They come with a set of business pains. They know that leads are being lost, transparency is lacking, managers are working manually, reporting takes too long, and processes depend too heavily on specific individuals. But there is a big gap between understanding the problem and having a clear solution architecture.

This is exactly where the project model starts to break down.When implementation is structured as a one-time engagement with a fixed scope from the start, it assumes that the key decisions can be made upfront. In reality, however, many decisions only become clear during the process itself: when the team starts using the system, real bottlenecks are uncovered, and it becomes clear which fields are needed, which integrations are critical, and which automations are still premature. According to Dmitrii, one of the main reasons for these failures is that businesses almost always come not with a clear solution architecture, but with a general sense of chaos in their processes. And today, the role of an integrator is not simply to “build a system based on the brief,” but to help a company move toward a functioning management model. We have seen this many times. Formally, a project may be considered finished. But in reality, the work does not stop there: adaptation begins, logic gets refined, the structure evolves, processes are fine-tuned, and the team needs training. The system does not remain static — it has to evolve along with the business. At some point, it becomes clear: implementation is not a one-time milestone, but a living process. Why we at Business Lab moved away from one-off projects At Business Lab, we work with companies that do not simply need a CRM “installed.” They need a manageable business infrastructure: sales, pipelines, customer journeys, automations, analytics, financial processes, and operational workflows. The issue is not with the project idea itself, but with the fact that a business is almost never standing still. While one part of the system is being implemented, the company’s team may already be changing, the sales funnel may be evolving, markets may shift, the product line may expand, or priorities may change. As a result, even a high-quality project soon requires continued work. That is why we moved to a different approach from the outset: first, we create a working system prototype, launch the basic configuration, and let the team begin using it. Then we develop the solution step by step. We do not try to lock in an “ideal future-state picture” at the very beginning. Instead, we build the system iteratively, based on real processes rather than assumptions about them. For Business Lab founders Ivan Osotov and Dmitrii Solovev, this became a core management principle: not to promise the client an “ideal scheme on paper,” but to build a system capable of withstanding real operational load. That is why, at our company, implementation is viewed as a process of developing business infrastructure. In essence, that is what the subscription model is: not one big project, but the continuous development of the system alongside the business. What changes for the client Under the traditional project mindset, the client often expects that everything can be designed once, approved once, and delivered as a fully functioning finished system. Within a subscription-based model, we look at reality differently: a system will only work well if it is continuously developed, adapted, and improved. This gives the client several important advantages. First, the business gets results faster. There is no need to wait months for the full scope of work to be completed. Even at the first stage, it is possible to assemble a working configuration and start using it in real operations. Second, the cost of mistakes goes down. If not everything is predicted perfectly at the start, it does not become a problem for the whole project. The system can be refined as new information emerges. Third, the quality of decisions improves. We rely not on an abstract technical brief, but on the team’s actual experience: what truly works, what slows things down, where data is missing, which automations create value, and which ones are not needed yet. And finally, the client is not left alone with the system after “project handover.” They have a team that continues helping the system deliver results. As Dmitry says, value for the client arises not at the moment of launch, but at the moment the system truly starts helping the business work faster, more transparently, and more sustainably. That is why, for Business Lab, it is critically important not just to implement a tool, but to bring it to the point where it becomes a practical daily business system. Why this is especially visible in ecosystems like Zoho This shift is particularly noticeable in Zoho-based projects. And the reason is not only the platform itself, but the way modern ecosystems are structured. Where CRM used to be seen as a standalone tool for the sales department, today we are talking about connected systems: sales, marketing, finance, support, recruiting, documents, analytics, integrations, and automation. The more integrated a company’s infrastructure becomes, the less sense there is in the old approach of “implement it once and forget about it.” An ecosystem like Zoho is designed for ongoing development by nature. Today, a company implements CRM and basic deal logic. Tomorrow, it adds communication automation. Then it optimizes analytics, billing, customer service, internal processes, and integrations with email, telephony, and other services. It is impossible to realistically treat all of this as a one-time project. That is why, in such systems, a subscription-based model is not just convenient — it is organic. This becomes especially clear during periods of business growth: when a company enters a new market, strengthens sales, scales its team, or complicates its financial structure, the system inevitably requires new logic. And the broader the ecosystem, the more obvious it becomes that it cannot be “closed out as a project.” How the role of the integrator changes In the project model, the integrator is an external contractor who is expected to complete an agreed scope of work. In the subscription model, the integrator becomes more like an extension of the client’s internal team. For us, this means that Business Lab’s role is not simply to configure fields, pipelines, and automations. Our goal is to make the system work toward business outcomes: helping the company process leads faster, see the funnel more clearly, control processes, reduce manual work, and increase transparency and manageability. This is no longer a classic “client-contractor” relationship. It is a much closer working partnership, where decisions are made in the context of the client’s daily operational reality. Our focus is on making sure the implementation truly fits into the company’s real work: into the team’s actions, the management logic, and the rhythm of the business. Because of this, Business Lab operates as an operational partner in the development of the system. Why the subscription model is more economically sustainable There is another important factor: economics. One-off projects often feel psychologically simpler: one budget, one launch, one decision point. But it is precisely in project work that unexpected costs arise most often — when requirements change, new inputs appear, gaps in logic are discovered, and additional development or a redesign of part of the architecture becomes necessary. The subscription model spreads the load and makes system development more manageable. Instead of trying to anticipate everything in advance and place it into one large budget, the company invests in its development as real priorities and real business tasks emerge. This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable. In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt. What we consider the biggest mistake Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start. In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it. That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling. This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

When implementation is structured as a one-time engagement with a fixed scope from the start, it assumes that the key decisions can be made upfront. In reality, however, many decisions only become clear during the process itself: when the team starts using the system, real bottlenecks are uncovered, and it becomes clear which fields are needed, which integrations are critical, and which automations are still premature.

According to Dmitrii, one of the main reasons for these failures is that businesses almost always come not with a clear solution architecture, but with a general sense of chaos in their processes. And today, the role of an integrator is not simply to “build a system based on the brief,” but to help a company move toward a functioning management model.

We have seen this many times. Formally, a project may be considered finished. But in reality, the work does not stop there: adaptation begins, logic gets refined, the structure evolves, processes are fine-tuned, and the team needs training. The system does not remain static — it has to evolve along with the business.

At some point, it becomes clear: implementation is not a one-time milestone, but a living process.

At Business Lab, we work with companies that do not simply need a CRM “installed.” They need a manageable business infrastructure: sales, pipelines, customer journeys, automations, analytics, financial processes, and operational workflows.The issue is not with the project idea itself, but with the fact that a business is almost never standing still. While one part of the system is being implemented, the company’s team may already be changing, the sales funnel may be evolving, markets may shift, the product line may expand, or priorities may change. As a result, even a high-quality project soon requires continued work. That is why we moved to a different approach from the outset: first, we create a working system prototype, launch the basic configuration, and let the team begin using it. Then we develop the solution step by step. We do not try to lock in an “ideal future-state picture” at the very beginning. Instead, we build the system iteratively, based on real processes rather than assumptions about them. For Business Lab founders Ivan Osotov and Dmitrii Solovev, this became a core management principle: not to promise the client an “ideal scheme on paper,” but to build a system capable of withstanding real operational load. That is why, at our company, implementation is viewed as a process of developing business infrastructure. In essence, that is what the subscription model is: not one big project, but the continuous development of the system alongside the business. What changes for the client Under the traditional project mindset, the client often expects that everything can be designed once, approved once, and delivered as a fully functioning finished system. Within a subscription-based model, we look at reality differently: a system will only work well if it is continuously developed, adapted, and improved. This gives the client several important advantages. First, the business gets results faster. There is no need to wait months for the full scope of work to be completed. Even at the first stage, it is possible to assemble a working configuration and start using it in real operations. Second, the cost of mistakes goes down. If not everything is predicted perfectly at the start, it does not become a problem for the whole project. The system can be refined as new information emerges. Third, the quality of decisions improves. We rely not on an abstract technical brief, but on the team’s actual experience: what truly works, what slows things down, where data is missing, which automations create value, and which ones are not needed yet. And finally, the client is not left alone with the system after “project handover.” They have a team that continues helping the system deliver results. As Dmitry says, value for the client arises not at the moment of launch, but at the moment the system truly starts helping the business work faster, more transparently, and more sustainably. That is why, for Business Lab, it is critically important not just to implement a tool, but to bring it to the point where it becomes a practical daily business system. Why this is especially visible in ecosystems like Zoho This shift is particularly noticeable in Zoho-based projects. And the reason is not only the platform itself, but the way modern ecosystems are structured. Where CRM used to be seen as a standalone tool for the sales department, today we are talking about connected systems: sales, marketing, finance, support, recruiting, documents, analytics, integrations, and automation. The more integrated a company’s infrastructure becomes, the less sense there is in the old approach of “implement it once and forget about it.” An ecosystem like Zoho is designed for ongoing development by nature. Today, a company implements CRM and basic deal logic. Tomorrow, it adds communication automation. Then it optimizes analytics, billing, customer service, internal processes, and integrations with email, telephony, and other services. It is impossible to realistically treat all of this as a one-time project. That is why, in such systems, a subscription-based model is not just convenient — it is organic. This becomes especially clear during periods of business growth: when a company enters a new market, strengthens sales, scales its team, or complicates its financial structure, the system inevitably requires new logic. And the broader the ecosystem, the more obvious it becomes that it cannot be “closed out as a project.” How the role of the integrator changes In the project model, the integrator is an external contractor who is expected to complete an agreed scope of work. In the subscription model, the integrator becomes more like an extension of the client’s internal team. For us, this means that Business Lab’s role is not simply to configure fields, pipelines, and automations. Our goal is to make the system work toward business outcomes: helping the company process leads faster, see the funnel more clearly, control processes, reduce manual work, and increase transparency and manageability. This is no longer a classic “client-contractor” relationship. It is a much closer working partnership, where decisions are made in the context of the client’s daily operational reality. Our focus is on making sure the implementation truly fits into the company’s real work: into the team’s actions, the management logic, and the rhythm of the business. Because of this, Business Lab operates as an operational partner in the development of the system. Why the subscription model is more economically sustainable There is another important factor: economics. One-off projects often feel psychologically simpler: one budget, one launch, one decision point. But it is precisely in project work that unexpected costs arise most often — when requirements change, new inputs appear, gaps in logic are discovered, and additional development or a redesign of part of the architecture becomes necessary. The subscription model spreads the load and makes system development more manageable. Instead of trying to anticipate everything in advance and place it into one large budget, the company invests in its development as real priorities and real business tasks emerge. This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable. In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt. What we consider the biggest mistake Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start. In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it. That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling. This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

The issue is not with the project idea itself, but with the fact that a business is almost never standing still. While one part of the system is being implemented, the company’s team may already be changing, the sales funnel may be evolving, markets may shift, the product line may expand, or priorities may change. As a result, even a high-quality project soon requires continued work.

That is why we moved to a different approach from the outset: first, we create a working system prototype, launch the basic configuration, and let the team begin using it. Then we develop the solution step by step. We do not try to lock in an “ideal future-state picture” at the very beginning. Instead, we build the system iteratively, based on real processes rather than assumptions about them.

For Business Lab founders Ivan Osotov and Dmitrii Solovev, this became a core management principle: not to promise the client an “ideal scheme on paper,” but to build a system capable of withstanding real operational load. That is why, at our company, implementation is viewed as a process of developing business infrastructure.

In essence, that is what the subscription model is: not one big project, but the continuous development of the system alongside the business.

Under the traditional project mindset, the client often expects that everything can be designed once, approved once, and delivered as a fully functioning finished system.

Within a subscription-based model, we look at reality differently: a system will only work well if it is continuously developed, adapted, and improved.

This gives the client several important advantages.

First, the business gets results faster. There is no need to wait months for the full scope of work to be completed. Even at the first stage, it is possible to assemble a working configuration and start using it in real operations.

Second, the cost of mistakes goes down. If not everything is predicted perfectly at the start, it does not become a problem for the whole project. The system can be refined as new information emerges.

Third, the quality of decisions improves. We rely not on an abstract technical brief, but on the team’s actual experience: what truly works, what slows things down, where data is missing, which automations create value, and which ones are not needed yet.

And finally, the client is not left alone with the system after “project handover.” They have a team that continues helping the system deliver results.

As Dmitry says, value for the client arises not at the moment of launch, but at the moment the system truly starts helping the business work faster, more transparently, and more sustainably. That is why, for Business Lab, it is critically important not just to implement a tool, but to bring it to the point where it becomes a practical daily business system.

This shift is particularly noticeable in Zoho-based projects. And the reason is not only the platform itself, but the way modern ecosystems are structured.Where CRM used to be seen as a standalone tool for the sales department, today we are talking about connected systems: sales, marketing, finance, support, recruiting, documents, analytics, integrations, and automation. The more integrated a company’s infrastructure becomes, the less sense there is in the old approach of “implement it once and forget about it.” An ecosystem like Zoho is designed for ongoing development by nature. Today, a company implements CRM and basic deal logic. Tomorrow, it adds communication automation. Then it optimizes analytics, billing, customer service, internal processes, and integrations with email, telephony, and other services. It is impossible to realistically treat all of this as a one-time project. That is why, in such systems, a subscription-based model is not just convenient — it is organic. This becomes especially clear during periods of business growth: when a company enters a new market, strengthens sales, scales its team, or complicates its financial structure, the system inevitably requires new logic. And the broader the ecosystem, the more obvious it becomes that it cannot be “closed out as a project.” How the role of the integrator changes In the project model, the integrator is an external contractor who is expected to complete an agreed scope of work. In the subscription model, the integrator becomes more like an extension of the client’s internal team. For us, this means that Business Lab’s role is not simply to configure fields, pipelines, and automations. Our goal is to make the system work toward business outcomes: helping the company process leads faster, see the funnel more clearly, control processes, reduce manual work, and increase transparency and manageability. This is no longer a classic “client-contractor” relationship. It is a much closer working partnership, where decisions are made in the context of the client’s daily operational reality. Our focus is on making sure the implementation truly fits into the company’s real work: into the team’s actions, the management logic, and the rhythm of the business. Because of this, Business Lab operates as an operational partner in the development of the system. Why the subscription model is more economically sustainable There is another important factor: economics. One-off projects often feel psychologically simpler: one budget, one launch, one decision point. But it is precisely in project work that unexpected costs arise most often — when requirements change, new inputs appear, gaps in logic are discovered, and additional development or a redesign of part of the architecture becomes necessary. The subscription model spreads the load and makes system development more manageable. Instead of trying to anticipate everything in advance and place it into one large budget, the company invests in its development as real priorities and real business tasks emerge. This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable. In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt. What we consider the biggest mistake Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start. In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it. That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling. This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

Where CRM used to be seen as a standalone tool for the sales department, today we are talking about connected systems: sales, marketing, finance, support, recruiting, documents, analytics, integrations, and automation. The more integrated a company’s infrastructure becomes, the less sense there is in the old approach of “implement it once and forget about it.”

An ecosystem like Zoho is designed for ongoing development by nature. Today, a company implements CRM and basic deal logic. Tomorrow, it adds communication automation. Then it optimizes analytics, billing, customer service, internal processes, and integrations with email, telephony, and other services. It is impossible to realistically treat all of this as a one-time project.

That is why, in such systems, a subscription-based model is not just convenient — it is organic.

This becomes especially clear during periods of business growth: when a company enters a new market, strengthens sales, scales its team, or complicates its financial structure, the system inevitably requires new logic. And the broader the ecosystem, the more obvious it becomes that it cannot be “closed out as a project.”

In the project model, the integrator is an external contractor who is expected to complete an agreed scope of work. In the subscription model, the integrator becomes more like an extension of the client’s internal team.For us, this means that Business Lab’s role is not simply to configure fields, pipelines, and automations. Our goal is to make the system work toward business outcomes: helping the company process leads faster, see the funnel more clearly, control processes, reduce manual work, and increase transparency and manageability. This is no longer a classic “client-contractor” relationship. It is a much closer working partnership, where decisions are made in the context of the client’s daily operational reality. Our focus is on making sure the implementation truly fits into the company’s real work: into the team’s actions, the management logic, and the rhythm of the business. Because of this, Business Lab operates as an operational partner in the development of the system. Why the subscription model is more economically sustainable There is another important factor: economics. One-off projects often feel psychologically simpler: one budget, one launch, one decision point. But it is precisely in project work that unexpected costs arise most often — when requirements change, new inputs appear, gaps in logic are discovered, and additional development or a redesign of part of the architecture becomes necessary. The subscription model spreads the load and makes system development more manageable. Instead of trying to anticipate everything in advance and place it into one large budget, the company invests in its development as real priorities and real business tasks emerge. This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable. In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt. What we consider the biggest mistake Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start. In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it. That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling. This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

For us, this means that Business Lab’s role is not simply to configure fields, pipelines, and automations. Our goal is to make the system work toward business outcomes: helping the company process leads faster, see the funnel more clearly, control processes, reduce manual work, and increase transparency and manageability.

This is no longer a classic “client-contractor” relationship. It is a much closer working partnership, where decisions are made in the context of the client’s daily operational reality.

Our focus is on making sure the implementation truly fits into the company’s real work: into the team’s actions, the management logic, and the rhythm of the business. Because of this, Business Lab operates as an operational partner in the development of the system.

There is another important factor: economics.

One-off projects often feel psychologically simpler: one budget, one launch, one decision point. But it is precisely in project work that unexpected costs arise most often — when requirements change, new inputs appear, gaps in logic are discovered, and additional development or a redesign of part of the architecture becomes necessary.

The subscription model spreads the load and makes system development more manageable. Instead of trying to anticipate everything in advance and place it into one large budget, the company invests in its development as real priorities and real business tasks emerge.This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable. In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt. What we consider the biggest mistake Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start. In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it. That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling. This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

This is especially important in the current environment. Businesses have become more cautious about large one-time investments, while at the same time the requirements for IT systems continue to grow. In this situation, a model of ongoing development proves to be both more flexible and more sustainable.

In Dmitry’s observation, an iterative format also gives the client a stronger sense of control: the company understands better what it is paying for, which changes are being implemented now, and what effect those changes are producing. This reduces the tension that often appears in large projects where the budget has already been spent but the results are not yet fully felt.

Looking across dozens of cases, the biggest mistake is almost always the same: trying to build the perfect system from the very start.

In practice, this rarely works. Not because the business request is poor or the team lacks expertise, but because a system only begins to truly live when real work starts happening inside it.

That is why we at Business Lab no longer look at implementation as “one big project.” We see it as a process: first the foundation, then development, then adaptation and scaling.This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch. As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience. Why the market is moving the same way What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm. Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it. That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure. In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

This approach requires more discipline, more involvement, and a much closer connection with the client. But it is exactly this approach that produces results that do not fall apart a month after launch.

As Dmitrii puts it, the most common management mistake is trying to “think the system through to perfection” before it has even started working. In practice, a much stronger approach is to build the foundation quickly, let the business start using the system, and then develop it further based on real data and real team experience.

What today may still look like an individual approach used by certain integrators is gradually becoming the new market norm.

Companies are increasingly understanding that an IT system is not a static object. It is part of a living business — and therefore it has to evolve with it.

That is why the shift from projects to subscriptions is not just a change in the commercial model. It reflects deeper changes: businesses are stopping seeing implementation as a one-time конечный task and are beginning to see it as the managed development of infrastructure.In this sense, the market is changing not just the payment format, but its very attitude toward technology. To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.

In this sense, the market is changing not just the payment format, but its very attitude toward technology.

To a large extent, it is experts like Dmitrii Solovev and Ivan Osotov who are shaping this new understanding of implementation today — not as the sale of a system, but as the creation of a working operational environment. And the more businesses face the need for flexibility, transparency, and constant adaptation, the more natural the shift from one-off projects to a subscription model becomes.