Building Software In-house: Is It A Good Idea? (Build vs Buy)
Cost and Control. While these two factors shouldn’t be the only key drivers behind your decision to push ahead with a project or not, let’s face it – they often play a major role.
Organisations will generally want to minimise cost while maintaining as much control as possible.
As a result of these key motivating factors, when it comes to the implementation of new software, organisations will often have to weigh-up the pros and cons of two different routes – build from scratch in-house or buy something ready-made and out of the box.
While on the face of it, it may seem like the better route would be to build software in-house, giving you complete ownership over it, it’s not quite as straightforward as that.
In this blog we will present the key things you need to take into account when comparing building software vs. buying software.
Is it expensive to build your own software?
The unavoidable truth is that each route has the potential to cost you more than you would have hoped. But while many businesses may try to convince themselves that building software in-house will be cheaper and easier, this rarely turns out to be the case.
Cost should be your first concern. As Scalyr, a log management and operational visibility software provider, says, “building software can be expensive if the software is large and complex”.
One of the reasons for this is the fact that, if you do choose to go down the route of developing your own software in-house, you’ll need to manage the project, build a team and estimate (as best you can) how much it’s going to cost.
One of the risks of taking this approach is that – even if you have experience of managing such projects previously – it’s always difficult to provide an accurate estimate of how much it will cost. Unforeseen problems can arise at any time and put a spanner in the works, resulting in delays and spiralling costs.
>>> More from the HICX blog: What is Supplier Onboarding?
The following figures from McKinsey make it clear just how damaging inaccurate cost estimations and project overruns can be: “One large retailer started a $1.4 billion effort to modernize its IT systems, but the project was eventually abandoned. As the company fell behind its competitors, it initiated another project—a new system for supply-chain management—to the tune of $600 million. When that effort failed, too, the retailer had to file for bankruptcy.”
If (or rather when) such issues arise, you then have another choice to make – do you continue with the project and battle your way through, or do you change the scope of the project or even cancel it all together?
Even if you choose to persevere, you will face delays. “When projects take longer than expected to finish, you’re stuck spending more and more money before the application is even ready to use.” (Scalyr)
Worse still, unexpected costs that stem from technology projects can quickly become considerable.
According to software design and development consultancy Atomic Object, if your “ideal system has a reasonable amount of complexity, the custom solution will cost more than the off-the-shelf solution. In our experience, assuming you hire an experienced external team to build your software, that difference can cost from twice to 20 times more.”
Building vs Buying: key cost factors to consider (at a glance)
+ positive: as it’s an internal project, your organisation can decide how much it wants to spend on such a project
+ positive: while the upfront cost of building a custom software solution may be higher than buying one, the long-term cost of implementation may be lower (e.g. for example, with no ongoing software license fees to pay)
– negative: building your own solution in-house requires you to build a team to do it. Good software developers don’t come cheap
– negative: (in-house) IT projects are well-known for experiencing major problems and costing far more than the estimated amount
– negative: the temptation to reduce costs could lead to corners being cut and a solution that’s not fit-for-purpose, as opposed to a specialised vendor solution which fits your needs ‘out of the box’
Does building software in-house instead of buying from a vendor give you more control?
Again, this is an interesting area to look at, and maybe the answer isn’t quite as obvious as it first seems.
You’d be forgiven for thinking that opting to build a software solution within your organisation would give you more control than buying one from a vendor. You own it, you can change it whenever you like – you have control. Well, it’s not quite as simple as that.
Yes, if you build software in-house then you technically have the ability to change it whenever you want, as opposed to buying something ready-made that you don’t have a direct say over. But there are still potential issues with this approach.
Building in-house software that is ‘bespoke’ to your organisation means you are reliant on the developers who built it.
>>> More from the HICX blog: 5 Key Business Processes for Supplier Master Data Management
Depending on how many people you hired during the development phase, are they all going to be kept on after the project is completed? If not, who is going to maintain the software and fix any bugs going forward? Is it built in such a way that another developer will be able to come in and easily edit the source code?
RL Solutions, a global provider of cloud-based healthcare software, put forward the argument that “lock-in is an issue no matter which option you choose: build or buy.”
“Whether that is your own internal IT team or a vendor, from an end-user perspective the lock-in is the same. You are now at the mercy of the people who built the solution.”
When it comes to vendor software, you (should) actually have more influence than you first think, depending on who you choose to work with.
No, you won’t ‘own’ the source code, but you will be able to provide feedback, suggest changes and have a say on updates, features and releases.
Organisations that buy software from vendors now have much more of a say than they used to, because of the way the market has changed and the stiff competition that exists.
Of course, if you go down the route of building your own software in-house then you can do this internally as well, without having to worry about your partner’s roadmap not aligning with yours.
A lot of it comes down to which vendor solution you choose. Many of the big-name suites lack any kind of flexibility and, in the words of consulting firm AT Kearney, instead “end up woefully underutilized, based on old architecture, and functionally inadequate.” So even if you do go down the vendor route, you still have to do your due diligence.
However, working with the right vendor will give you flexibility and a much higher level of customer involvement in the product design and enhancement process.
“Software vendors have to be much more responsive to customers than they have in the past. Those vendors that ignore customer feedback and simply march to their own tune will not survive.” (RL Solutions)
So, to sum all this up, if you want the benefits of having a degree of ‘control’ without the hassle of software maintenance and upkeep, go with vendor software!
Building vs Buying: key control factors to consider (at a glance)
+ positive: if you build it, you own it. You don’t have to worry about competing with other customers for a vendor’s attention when it comes to creating tickets for bug fixes or requesting changes
+ positive: building a custom software solution in-house gives you the freedom to choose which third-party applications you integrate with, whereas some vendor solutions may be more limited in terms of API integration
+ positive: depending on how you want to grow, a custom-built solution may give you more scalability than a rigid system which isn’t built with flexibility in mind
– negative: you may not be ‘locked-in’ to a vendor by choosing to build it yourself, but you’ll be reliant on your in-house developers when it comes to maintaining, fixing or upgrading your in-house system
– negative: the competition between vendors means they are constantly investing in improving their software and meeting the demands of their customers. If you build your own solution, will you have the ongoing resources available to improve it?
– negative: do you know what your competitors are doing? While you may be stuck in development hell trying to build your own software, the competition may be buying specialised off-the-shelf solutions that provide faster implementation, better results and competitive advantage
What are the risks of building software in-house over buying it?
One of the attractions of creating your own software is the idea that doing so will result in a solution that meets all of your organisation’s needs and which can be moulded to fit your exact requirements – rather than having to fall in line with a software vendor’s idea of what constitutes ‘best practice’ – but even this notion can be deceiving.
The appeal of building your own software is the notion that, by doing so, all of your organisation’s requirements can be met. However, this is little more than a mirage. The constraints – budgetary or otherwise – that are placed on every IT project mean that there are always going to be requirements that won’t be met.
According to analytics firm Gallup, the vast majority of companies fail to meet 100% of their projects, while IT projects had an average overrun of 27% and “one in six projects had a cost overrun of 200% on average and a schedule overrun of almost 70%.”
This may be stating the obvious, but sometimes the obvious needs to be stated – building good software is hard. If this is a path you’re considering, you need to be aware of the risks involved, and the reasons why you may not be able to meet all of your requirements.
>>> More from the HICX blog: Supplier Master Data Management 101
One of the major risks (as alluded to earlier) is that your software project may not even come to fruition! The IT world is infamous for its rate of failure when it comes to seeing projects either finish on time or on budget.
While it would be almost impossible to work out what the precise failure rate is for IT projects because of the different ways of measuring them, some studies suggest that only about a third of all IT projects finish on time, about 40% are delivered on budget and most organisations reported experiencing at least project failure in the last year or so (Tech Target).
That’s not to say that every IT project or software-building initiative is certain to fail.
It just means that you need to be aware of the risks, time and expenditure involved in such a project, and the fact that after investing time and money in it it could all come to nothing. If that does happen, you may find it difficult to justify any further investment to the organisation’s leaders.
Building vs Buying: key risk factors to consider (at a glance)
+ positive: as touched on above, building software in-house gives you complete control over how it functions, as opposed to yielding control by buying something from a vendor. As such, if you need a system that meets specific regulatory or compliance standards, you can guarantee this by creating your own from scratch
+ positive: buying a third-party solution that’s outside of your control is always going to come with an element of risk. You need to be certain that the vendor’s security policies and standards are of a high-standard to try and minimise that risk. Of course, there’s also always a chance that the vendor itself may run into difficulties and cease operating as a business
– negative: one of the obvious risks involved in creating your own software is that there’s always a danger you will be subject to hacking attempts. According to Cisco, 31% of organisations have experienced cyber-attacks on their technology infrastructure – and this number is only going to increase. If you choose to build instead of buy, you need to be sure that your security is of a very high standard. If not, you’re going to be vulnerable
– negative: as mentioned earlier, technology projects can face significant problems. These include running late, going over budget, or both – and the costs associated with these are high
Conclusion – it’s better to buy
Our view is that it’s often better for organisations to invest in the software that supports them in doing what they do best, rather than getting caught up in trying to build it in-house. (Of course, it’s unsurprising that we’d put this case forward given that we are a vendor.)
It’s a cost-effective approach that gives you access to specialist software and the expertise of the company that built it. Not only that, but it also takes away the risk of getting bogged down in an IT project that can easily sail past the deadline and shoot over budget.
When organisations do go down the route of choosing to work with a vendor, it’s important for each party to be clear on what they expect from one another. Truth be told, as a vendor, it doesn’t make sense to work with customers who aren’t excited by the prospect of working together going forward. We have a clearly-defined roadmap for the future and are always thinking about how we can better support our partners.
Having said that, it’s always imperative that you gain a complete and thorough understanding of what your organisation’s needs are and what’s available on the market before reaching a final decision. Everyone has different opinions on what the right or wrong path is – and some opinions are more valid than others – meaning that ultimately you need to make sure you do your research and reach the right conclusion for your circumstances, backed up with appropriate evidence.
Check out our detailed white papers, reports and videos in our Resources section here >>>
Posted in
