Defining IT Landscape - Buy vs Build
When is better to buy software vs make it in-house?
Hey, fellow Leader 🚀,
I am Artur and welcome to my weekly newsletter. I am focusing on topics like Project Management, Innovation, Leadership, and a bit of Entrepreneurship. I am always open to suggestions for new topics. Feel free to reach me on Substack and share my newsletter if it helps you in any way.
One of the toughest decisions an IT Manager needs to make is to decide when the company should buy software, already tested and produced by a provider, versus doing the software completely in-house. The challenge comes from the fact there is no easy direct answer and depends highly on the situation or company.
To be completely honest, not all companies have the ability to make this decision. So to have the “Buy vs Build” option for the company’s IT strategy, it needs to have a significant number of pre-requisites. These requisites might be very challenging for startups and SMEs
Has the company the required skillset and developers?
Building software is no easy task. It requires knowledge from different areas of IT aggregated into one single product. For a company to start and build new software requires an IT Architect who will define the technologies and the implementation strategy to make the product a reality; A Business Analysts who can translate the requirements into a comprehensive strategy of Operational effectiveness with an IT solution; And a team of talented Developers who already have the skills to make the software from the bottom up. Of course, they need a Project Manager to coordinate and articulate all the moving parts together to make sure the project is on budget, scope, and schedule.
The project team needs to use a methodology (Agile or Waterfall) and each methodology has dedicated actors (Product Owners, Testers, Subject Matter Experts (SMEs) who need to be defined and responsibilities set. Typically the IT Architect is biased towards the same technologies, so discussions are inevitable about which technologies and solutions to go forward and how much it costs, and so on.
Not all companies can afford to decide between buying or building a software product. If a given company doesn’t have the required skills and methodologies, the decision should tend towards buying. If the company decides the software is directly connected to its strategy and added value, it makes sense to build in-house if it can afford the investment.
Where does the software fit the company’s strategy?
This is one of the questions that should be asked before any decision. Building software from scratch is not cheap, and sometimes the efforts doesn’t payout the gains.
I am not a big fan of buying software that is directly connected with the company’s main strategy or main added value for their clients. A piece of software that is sold in the market tends to offer standard features but can accommodate some customization. The providers rely on their ability to customize the solution for each client, however, these customizations tend to be very restricted.
Having decided to buy a software product can be seen as a blessing or a curse. In a way, a company can have a set of features delivered in a very short timeframe, and have the cost controlled during the license’s duration. However, some of its competitors might have the same features with little difference. If the software is directly connected with the company’s strategy and value proposition, flexibility and having a unique offer are paramount.
In the case of ERPs, CRMs, or other operational tools, I tend to go to off-the-shelf software. It’s still an important piece of software, critical in the company’s operation, but at the end of the day, it doesn’t matter how a stock of merchandise is handled since it’s accurate in the IT system. The CEO won’t make a company pivot the strategy because of the way the company invoices its clients. Operational processes tend to be the same and are there just to make the company run. Unless the company wants to do something so disruptive to its Operations compared with its competition, that justifies making software tailored for the company’s processes.
The pros and cons of building in-house
Building the software in-house provides great flexibility on how and when the features are implemented. It provides custom abilities to handle different aspects of their core business that are unique for the company. The IT Development team is king for managing the data, the flows, and all the IT Architecture. The team can design the best way to integrate with other IT solutions inside the company.
The software can allow distinct and customizable processes for delivering a product. The know-how and agency about how the software is built the business requirements are entirely from the Development team and it’s internal stakeholders.
Also, it comes with an increased investment value and run costs. Having in-house software is not cheap. Is not only the cost of building the software for the first deployment. Is the ongoing work that the software will have, the bug fixing, the testing, the changes to accommodate security patches, and so on. But is by far, what can tell apart companies from their competitors if technology is one of the drivers for strategy.
The pros and cons of buying software from a provider
The software is already done, is ready to be installed, it has already a set of juicy features from day 0. Typically is already widely tested (except software from Startups), and already takes into account a set of regulations and reporting needs. This is all great news, however, an IT Manager needs to be mindful that the tolerance for customization is small. Ideally, providers wait for a set of clients to request the same features to be economically justifiable and implement them. This process might take months, if not years, if at all.
The added value for Software providers is to have a set of features that can be widely used by their clients. The providers have little to no incentive to put in place a feature that only 1 client requested. A client can request a quote sponsor a feature and contractually request exclusivity. Nevertheless, these kinds of improvements are never smooth sailing toward the final deployment, and the flexibility to change requirements mid-course is small and costly.
That’s why I truly believe of going for buying software for operational heavy processes. The software can already cover a set of requirements that can take years for the company to build on its own.
However, there is a tricky part. The integration with other systems.
Integration with other systems
In corporations, no software is isolated from one another. Integration between systems plays a big part. If not, the lack of system integration will come at the expense of manual work done by employees.
Even if the software is bought from a provider is important to study how it will communicate with other systems. The best strategy is to implement an API layer or any sort of ETL between the different systems. The main objective in mind is to make “easy” the task of replacing one system with another if the company decides.
To note that when a company buys software, in practice it buys a usage license for a set of years. For some time, the cost of the license is set and stable. Once the contract is over a negotiation might occur for a new price. The company might not have control of the cost increase or any other decision that goes against the company’s expectations and usages. A company might come to the realization that needs to replace the system altogether.
That’s it. If you find this post useful please share it with your friends or colleagues who might be interested in this topic. If you would like to see a different angle, suggest in the comments or send me a message on Substack.
Cheers,
Artur