Buy vs. build: Which strategy is better for your company?

Within the decalogue of frequently asked questions that technology manufacturers and service companies must face, there is one whose answer has not changed and should be taught in the first sales class. Why should we purchase the platform from a third party if we can do it ourselves? This question, usually formulated by the technology area, is known as the "technology question. "buy vs. build question" and typically occupies a significant portion of sales cycles for new technologies and digital solutions.

It is easy to conclude that there is not necessarily a single correct answer; at the extreme end of building everything, we would find IT areas that develop their own programming language, store all their data in machines they invented themselves, in on-premise systems. Borrowing Harari's idea of an information network, we basically find ourselves in the scenario of a notary's office where all the files have a manual copy in a filing cabinet whose logic is only understood by the bureaucrats who participate daily in its construction, far removed from any progress in the industry.

At the other extreme, we would find dozens of single-purpose technologies with little communication between them. A tower of Babel that constantly requires new technologies to connect the silos of information, becoming an additional layer of the onion that grows larger as information sharing needs increase. Likewise, the frustration of having to contract complex platforms for seemingly simple problems grows. This is the seed of the most common phrases in this microcosm: "I'm killing flies with a shotgun" and "we have a Ferrari parked".

Understanding then that Buy vs. Build is not a minor question, it is worth thinking about what should be the logic that helps to tip the balance to one side or the other. In practice, we ask ourselves and our clients seemingly simple questions that should help define the path:

Platform or practice? how to choose the best solution

My greatest mentor in technology sales used to say that can be made excellent CRM in Excel and a lousy CRM in the most advanced technologiesto illustrate how structural problems are not solved by investing only in technology, but in processes, strategy and equipment. That said, it is common to see teams that have developed a practice over the years, whether it is data analytics, centralizing consumer information or automating mass communication campaigns by their fingernails. When the solution to the problems of agility and scalability of simple processes becomes hiring more people, then you are really killing flies with a shotgun.

Core Business: aligning investment with your strategy

What is the company's mission and vision? What are the KPIs for the next three years? It is common to find variations on the same answers: "we want to sell more", "we want to sell more cheaply", "we want to sell our products more cheaply", "we want to sell our products more quickly". customer relations are longer term. In this sense, the company's efforts should be focused on these initiatives and the processes that support them. This in no way means that the development areas are not capable of large projects, but it is necessary to consider whether these investments respond to the company's core business and whether they will be scalable. There are cases in which they can become a spin-off, where a new source of income is opened. Others, where unfortunately there is not such a specific market or the competition is so strong in the sector that, no matter how appropriate the solution is, there is no will to collaborate with potential customers.

The business focus has another important point: be clear that the company's efforts will justify investments in maintaining and improving the platform. To put it more simply with an example: banks have focused their value proposition on the security of money and on offering portfolios that allow those savings to be put to use. We can count on them to continue investing in that direction. That option sounds more attractive than keeping the payroll under the mattress, even if we frequently invest those savings in reinforcing the mattress. (Paradoxically, the financial sector seems to be the most likely to opt for in-house developments).

Legacy systems: the challenge of deciding whether to modernize or build from the ground up

Many company developments are focused on keeping legacy systems in place, usually on premise, that house the company's core processes. Something like their reptilian brain, which simply cannot fail because it would bring down the rest of the system. This can get to the point where it is easier to start over again the assembly of structures than to migrate to more modern or efficient systems. Such custom developments for legacy systems may be limited by the capabilities of the legacy platforms, both as a data source and as a data destination:

Difficulty in APIficar, long processing times, programming languages in disuse... make legacy limitations derive in updated limitations. It is necessary to evaluate whether the project and the platform can be small steps towards supporting a grassroots transformation or federalizing the dependence on a specific system, or whether, on the contrary, it is doomed to fail to be deployed as a truly innovative project.

Keys to reduce risks in technology

This question is probably the most unpalatable to ask: is the company prepared to survive the absence of the Product Owner of the locally developed system? This opens up the conversation about learning resources, community support forums, learning ecosystem partners and number of professionals who know the platform in question. Doubts that usually do not appear in a RFP and answers that are often the protagonists when deciding to migrate from one platform to another.

Usually, these questions are complemented, when the discussion is opened, with other elements to be taken into account by decision-makers. The answers are often difficult to have ex ante, but they serve to shed light on what may come in the future:

1. Total cost of ownership (TCO): not only the initial price, but also maintenance, support, training and scalability costs.
2. Speed of implementation: A purchased platform can be ready in weeks, while in-house development can take years.
3. Technological risk and obsolescence: technology and the market change faster than internal development cycles.
4. Flexibility and customization: Third-party platforms may be more rigid, but an internally developed 100% can be adapted - at cost.
5. Impact on innovation: buying can free up resources to innovate in other key areas.

In short, the dilemma between building or buying should not be solved from technological pride or commercial pressure, but from a clear strategic vision: which decision brings us closer to our business objectives faster and more sustainably? Technology, whether owned or acquired, is a means and not an end; the real competitive advantage comes from how we integrate it, scale it and put it at the service of our value proposition. Whoever manages to balance speed to market with the robustness of their internal architecture will not only answer the "Buy vs. Build" question well, but will be better prepared for the questions that have yet to be asked.

Contact us at and let's find together the best alternative for your business.