A common business case is when a large company with a technological product wants to split due to internal disputes or differences of opinion. One of the shareholders wants to detach from the company and create a new entity.
The motivation behind such a decision frequently stems from differences in business vision, divergent expectations regarding the direction of the company’s development, and, consequently, the belief that further cooperation is pointless.
This decision is always challenging and usually tense for all parties involved. The parent company, which needs to share part of the software, and the new company taking it over naturally strive to maximize their own benefits.
This is a delicate moment for any company, requiring not only an understanding of the technological aspect of the split but also deep knowledge of change management and negotiations.
Without proper support and preparation, this process can become frustrating, lengthy, and costly, with long-term consequences for both sides.
How to avoid this?
IT Acquisition in Theory – Expectations
In an ideal world, technological acquisition looks like a well-oiled machine – the process is transparent and organized, and all necessary resources are readily available. A technological partner like ourselves, who helps in the IT transition, receives full access to critical project elements, ensuring seamless project continuation.
Typically, at the start of this process, we gain access to a project group on developer platforms like GitLab or GitHub. This organizational structure usually consists of 5 to 10 repositories, which form the foundation of the project’s functionality. We find various components within these repositories – from frontend and backend, through CRM systems, to marketing applications, data scraping tools, and test repositories.
In the dream scenario, these resources are transferred based on a precisely constructed contract, making the process smooth and without surprises. We receive the code and a comprehensive list of accesses to various services and platforms – such as Google Cloud, AWS, Azure, or tools like SendGrid, MailChimp, Pipedrive, or HubSpot.
IT Acquisition in Practice – Reality
In practice, the acquisition of an IT environment seldom unfolds according to such a scenario.
Instead of comprehensive access and a complete set of resources, we often receive only access to cloud services, fragmented information, and missing elements, such as tests or critical dependencies in the code.
We then start an investigation, reviewing available materials in search of missing elements essential for further work. Of course, in an ideal scenario, such an investigation would allow us to identify all necessary dependencies, but reality often differs.
This review is a discovery process that can reveal hidden dependencies, incomprehensible naming, or even key elements deemed irrelevant. By its very nature, the investigation is a lengthy, change-prone, and non-obvious process.
During the investigation, we encounter moments where access to different services is missing, or the parent company refuses to grant access, arguing that “they didn’t agree to this.” Disputes arise, for example, whether the customer database was part of the contract.
Well, the contract…
The Root of the Problem: A Poorly Drafted Contract
From our experience, the source of many issues during the technological takeover process is an imprecisely written contract. Businesses, in a rush and under time pressure, sign documents that do not adequately protect their interests, especially those of the newly emerging company.
The result is a situation where both parties lack clarity regarding the scope of the transferred resources, leaving the new company with software that may be incomplete or not in line with expectations.
Clauses mentioning “cloud data” without specifying which cloud it refers to is a typical example of such generalities.
Similarly, a contract might mention the transfer of a “service”, raising questions why the domain was not transferred – since the contract only mentioned “service”, not the domain. This leads to a situation where the domain, a key element for the service’s operation, remains the property of the previous company, which may not be understandable to the new owner.
Such clauses make the contract ineffective in ensuring a clear and comprehensive transfer of resources necessary for the service’s operation. Superficial treatment of key technological aspects in a contract full of generalities lays the foundation for many future problems, from the incompleteness of transferred resources to misunderstandings regarding the scope of responsibility and intellectual property.
The Consequences of a Poorly Drafted Contract
The consequences affect all parties involved in the technology takeover process.
Firstly, vague contractual clauses delay delivering necessary components, which can last for months. For the new company, such delays are frustrating and costly.
From the perspective of a technology company like ours, it is equally problematic because the team is ready to work but lacks the basic components – they are unavailable, and the contract with the client has already been signed.
Not knowing what to do due to lack of access or incomplete data, developers become emotional sponges for the frustration and stress of the client’s product owners.
Product owners, in turn, receive business tasks they cannot complete and become frustrated. This leads to internal conflicts, where discussions about what should be done become increasingly emotional.
As a result, not only the development team and product owners suffer, but also the client company itself, which has to bear the costs of empty work hours – paying for time in which work cannot be efficiently completed.
Thus, the key question remains…
How do you painlessly transition through IT infrastructure acquisition?
Well, we’ve seen this situation multiple times. And according to our experience, these are the necessary steps.
Step One: Consultations Before Signing the Contract
Solving or preventing these issues begins with consultations with an independent technology company like ourselves, even before signing the contract.
This approach helps prevent problems instead of solving them later. A cold start, meaning the preliminary review of contracts, is a critical step that identifies and eliminates potential ambiguities.
It may seem like an extra step, but it’s an investment that saves time and money in the long run. Consultations, often requiring up to a few hours, can provide valuable insights into what is essential in the contract and what might need to be clarified or added.
A technology expert can advise on constructing the contract clearly and comprehensively, precisely defining the scope of transferred resources, accesses, and responsibilities. They can also point out which elements are crucial for the service’s operation and should be included in the contract.
Additionally, this approach allows for better planning of the project work process. The technology company can suggest a gradual team engagement instead of putting the development team on standby to start work immediately, only to face frustration due to lack of access or incomplete data later.
Step Two: Reverse Engineering
A precisely written contract and access to code are crucial, but recreating the original business processes from the parent company is another challenge. This is where reverse engineering comes into play.
Reverse engineering is vital for recreating software’s functionality and architecture, as well as the business processes of the previous company. The aim is to understand system operations, and executed processes, and utilize this information for development and optimization.
Reverse engineering starts with inventorying available resources. Key information is often dispersed, found in code, or known by individuals from the previous company. We analyze fragmented and synthesize them into a cohesive system overview, identifying available resources and gaps or needed modifications.
This method reconstructs customer journeys and key business processes. Code and data analysis might reveal structured customer pathways, utilized landing pages, and their impact on conversion. This is vital when the new company needs to gain knowledge of these processes or information needs to be completed or updated.
Through technological investigation, we link code records with employee experiences, discovering system operations and inspiring implementable solutions in the new company.
Step Three: Technological Partnership
The third step in managing the technological acquisition process is choosing the right technological partner who will temporarily serve the role of the new company’s IT department and plant the seed for the future in-house tech team.
As a temporary technological partner, we deliver the necessary human resources—typically 3-4 people—and know-how and procedural support. This allows startups and new companies to focus on developing their business, confident that their technological needs are fully met.
This collaboration often lasts six months to a year, enabling the company to understand and specify its technological needs and develop internal IT competencies.
Our commitment to the project is often crucial for its initial success. We act as an incubator where the company can experiment, learn, and develop its technologies before deciding to internalize IT processes fully. We define development directions, test various solutions, and build solid foundations for future actions.
Ultimately, when the startup is ready, it can independently establish its IT department, often by hiring people who previously collaborated with them as part of our team. Our role at this point ends, but we leave behind a team well-acquainted with the project, its goals, and specifics, which is invaluable for a young company.
In this way, as your temporary technological partner, we provide momentary support and help build lasting, effective IT structures that will serve the company for many years. This approach minimizes the risks associated with the initial stage of technological development. It also accelerates the maturation process of internal IT competencies, which is crucial for the stable growth of any modern organization.
