Welcome to our latest issue of News from Europa. Today we are going to tackle a subject that is recurrent in the IT world: “Build versus Buy: is it necessary to develop one's solution with IT development or to buy a software package from the market?”. The answer depends on whoever thinks to provide the solution. As at StartEuropa we have a tradition of selling software we directly display the color and the bias that we introduce: we will develop the sales pitch to help you sell software. We assume that most of you have an innovative software solution and if you are an IT&S you have developed intellectual property that can speed up implementation. As you are in innovative markets, the alternative is either another software vendor like you (a little) or an IT development (a lot). Strengthening your sales pitch for software in the face of IT development is therefore entirely relevant.
The first insight to remind you is the fact that compared to the USA / Canada, the software culture is less widespread in Europe - as in the rest of the world. We saw in a previous newsletter that the North American market absorbs a little bit more than 50% of the world software market while its weight in the world GDP is half as much. In Europe, the share in the world software market is around 25%, in line with its weight in the world GDP. The reflex is clearly less to go towards software. The second insight is that developer IT resources are more important here. Europe has more than 6 million professional developers and has experienced steady growth in the developer talent pool, in contrast to the US, where the professional developer base has been static for the past two years around 4.3 million. This is reflected in the costs, which are therefore lower than yours. These resources are even more competitive when you go to Eastern Europe. Some of you already know this because you use offshore development for your own R&D in Poland, Ukraine, Belarus... Moreover, the European IT services providers (IT consulting, outsourcing and professional services) are plentiful and powerful. You probably know them because they also operate in North America: Accenture, Deloitte, KPMG, CapGemini, Atos, TSystem… By culture and interest, these service companies will lean towards the Build. They only embrace the Buy when it allows them to differentiate themselves from the Internal Build. This is a danger to be avoided for a software vendor who wants to control its total cost of ownership. With the experience of implementing ERPs, we have found that integrators make many specific developments around the core of the software package. This specific part allowed them to secure third-party application maintenance which suffered less from competition than the configuration of the software package. This should lead you to ask yourself another key question, with whom are you going to market your solutions: an IT&S integrator who will make a living out of the complexity of integration and the specifics that will ensure them a maintenance revenue or a partner like StartEuropa who has a software culture and who will make professional services like a software vendor?
The specific development suffers in the comparison with the software package from 2 main weaknesses: cost and implementation time. In this respect, let's pay attention to the latest argument that underlines the new DevOpps methods, Agile Development and the most recent build tools (such as Zero code...) to explain that the results of developments can more easily meet the wishes of internal customers and go faster and cheaper. The arrival of the Cloud has made life easier for these new rapid development techniques that rely on rapidly mobilizable resources such as PaaS or IaaS. It is interesting to see by the way that the Cloud reproduces this dichotomy between Build and Buy, with SaaS (=Buy) representing half of the Cloud, PaaS and IaaS the other half.
In a decision tree, we can distinguish 5 main families of decision criteria to be weighted:
Problem & Expertise
If the problem is unique and there are no software solutions, then the specific development option is a natural choice. We take as an assumption that you are providing a software solution to a business or industry problem. This recurring problem has justified the launch of your company. You will differentiate yourself from specific development by bringing an expertise that you will carefully highlight in use cases, presentations, white papers, success stories and product demonstrations. Remember that you will concentrate in the solution more and more functionalities and even good process practices. It is interesting in this regard to note that SaaS takes up the argument of ERP type software packages by integrating best practices - with an easier than expected upgrade. The accumulated expertise and functional depth will allow you to gain superiority over the specific. Our recommendation is to develop well the arguments emphasizing the expertise and the scope of the problems and address with care the business stakeholders.
Time & Urgency
The more urgent the need, the more the balance will tilt towards the software package, because in essence development will take time. Our recommendation is that in the sales cycle you can move up in the hierarchy because at a high level the decision makers are aware and in charge of mastering the urgency.
Control & Risk
These are the classic arguments in favor of the specific. With a software package you don't control the source code, there is a risk of relying on a third party for support and product evolutions, risk of poor integration with the legacy system. Whereas with a specific development, the IT team controls the source code, ensures maintenance and guides the evolution of the product. Proponents of specific development will point out the risks of working with a software vendor. Perennity, size, proximity, security, compliance with data regulations, risk of not having the right support, risk of entrusting the evolutions of the solution to the editor: you will have many risks to mitigate. Each of them should be carefully addressed, including the risk of integration into the customer's existing information system. We also strongly recommend accessing business and IT decision-makers in the sales cycle. Also consider developing a partnership approach with your customers.
Culture
An in-depth knowledge of the market enables us to get to know the culture of the companies. Companies that have very strong IT teams, like the banks for example, will tend to use them. We recommend to carefully address stakeholders in the sales cycle without preconceptions, including those who seem to be against a Buy approach (IT development team). Indeed, there are always other projects that require full use of these internal resources, which justify not defocusing these teams from working the core business components of their information system that can give them a competitive advantage.
"Can't you do better with your development resources, make them work on projects that are more exciting for internal teams and more strategic for the company? "
If these stakeholders are resistant to the arguments, we advise to insist on the business pole which will be the most sensitive to the Expertise and Urgency arguments and which may have bad experiences with internal delivery.
Budget & Total Cost of Ownership
This is a key decision factor that we left voluntarily last. It is indeed important to price the solution according to the value perceived by the business. As such, the price of the Buy solution is an adjustment variable in the negotiation. This will allow the value to be sold at the right level. In comparisons, all the costs should be correctly taken into account, this is called the Total Cost of Ownership. For the software package it is the price of the licenses as well as the configuration and the integration into the existing information system. For the Build, it is the initial development (business requirements, development, testing) but also the maintenance and future improvements. Normally the Buy formula, especially if it is in SaaS, is less expensive, because there are economies of scale. Share the big financial picture at a high level in the hierarchy because executives have global visibility, and over time, including costs that are not easily detected.
There may be situations of buy and build cohabitation. You can very well make a sale knowing that it is purely tactical, the client ramping up on the subject and wanting to carry out their own development in the long term. You know that you will temporarily be a supplier. This is perfectly acceptable, especially since we see that the temporary sometimes lasts in IT.
Finally, don't forget to keep the focus on the customer. Europeans greatly appreciate the consideration you give them. Creating and running the European user club should quickly figure on your development action plan. This will help cultivate loyalty as well as prepare for product developments. Some software vendors from a certain size tend to streamline developments and be less attuned to the market. The best ones continue to do so regardless of size, take the example of SAP who developed its ERP Transportation solution with CMA-CGM through a partnership approach.
In conclusion, when launching your business in Europe, we recommend that you take the threat of specific development seriously. We suggest that you strengthen your pitch in this direction. We encourage you to work with a partner who has the software culture. A partner who will be able to address the decision-makers at the right level in order to get enough sponsorship. This is the competence and know-how of StartEuropa. We are looking forward to exploring with you how to increase your business in Europe.