Build or Buy? The Eternal Internal Debate
Do we use internal resources to achieve a business outcome? Or do we buy a solution outright?
That’s the age-old question that companies have to wrestle with, whether they’re small family-owned businesses or large multinational enterprises.
Various factors that are linked to a business’ health—what stage a company is in, profitability, solvency, credit available, accounts receivable turnover, bandwidth of the team, etc. — might affect a business’ propensity to build or buy.
Whether you choose build or buy, getting the initial go-ahead can be problematic. A lot of bureaucratic processes and red tape can get in the way.
Here are some scenarios and considerations to help you find the best option for your company.
When to build software internally
Depending on how much money you have in the bank or your department’s policy on building versus buying, cost is probably the number one consideration in terms of adopting new enterprise software.
You may also want to consider building if the software is specific to your business and not available on the market. Unless it’s a unique scenario, say, if you’re a company that creates invoicing software and you’re processing payments, you probably don’t want to hand over a chunk of your margins to another company. It might have made sense at first before you had the team and infrastructure to do so, but now that you’re capable, you can start thinking about cutting out the middleman by building in-house.
For example, Treehouse built an internal social network for company use only, a Reddit-clone that worked wonders to boost morale and build company culture.
Customization is another reason to build internally instead of buying, if you want granular control over the functionality of the software. Perhaps the problem you’re solving is so unique that the solution needs to be customized to your own situation or workflow. You’re allowed the control to steer development to cater to your specific needs, although a deep domain knowledge is often required to build the right solution with all the functions you need to solve your problem. Make sure you account for this expertise on your team.
Internal resources are another thing to consider. Do you have full-time, skilled developers available on hand to ship products that are outside the regular scope of their jobs, or people who are hired specifically for this purpose? Keep in mind that these resources will be committed in the long-term to regularly maintain and update the software if needed.
But if you don’t have developer resources to spare or the ability to keep them on hand to support the product over time if needed, then you may want to consider buying a solution from a trusted vendor.
When to buy software
When you consider that solutions already exist to solve many business-related problems, which have dedicated their own time and resources to updating, maintaining and improving the software, it makes sense to buy in many scenarios.
If you’re in growth mode and looking to aggressively expand your business in areas where you don’t have deep domain knowledge, you may want to consider buying a solution you trust and can get up and running fast. For example, if you’re considering accelerating your sales cycle by nurturing leads through marketing automation, you’re likely not going to be building marketing automation software from scratch.
If there are already established products available that do the job and enable you to move faster without having to consider the support and maintenance resources, then you should consider choosing one—after properly evaluating your options, of course.
In terms of building a product, “internal resources” don’t necessarily mean only developer resources. There are also many other things you need to consider, such as expertise in the space of what you’re trying to build and a full understanding of a the problem.
Also, if a system goes down, who’s going to support it? Will they be fully capable of supporting it? Is it their full-time job and focus, or something they’ve been assigned? What about the infrastructure? Under whose department does this fall under and who will pay for server costs?
The tricky thing with building software is that there will be continual maintenance involved in terms of the changing demands of the software, customization, feature requests, integrations and so on. If this is a critical part of your operation that’s outside the core of your expertise, what’s the turnaround time to resolve something? If there are security issues or there’s been a breach, how long will take for IT to resolve the compromised software? These are all questions that need to be answered.
Buying something off-the-shelf, trusting in that system and molding your processes to fit the software vendors might be better than risking and betting on something you build yourself. You don’t know until you go down that hole. Many solutions out there already address specific problems and constantly improve based on customer feedback and industry trends to add features and build out functionality over time.
Consider the time you have to execute
We’re our own worst enemies when it comes to estimations, especially when it comes to shipping products that are “production ready". If a project is time sensitive and you don’t have the resources on hand in order to execute a vision, there’s no point in really entertaining the notion of building it in-house.
You may consider building if you’ve scoped out your project and fully understand what’s involved in building the product in terms of developer and designer resources, as well as the features you need, and the timeline coincides with when the software is needed (i.e it wasn’t “needed yesterday”). This is keeping in mind that it might take months to execute, test and deploy before you have any users.
Final verdict
So, should you build a solution in-house or buy an existing software?
Though it’s the non-answer we hate to hear, it really does depend on your unique situation.
That said, control is often the main reason that people choose to build instead of buy. But control can be an illusion. Control is ultimately given up if you start going further down the path of building something internally.
You’re at the whim of many different stakeholders that need to be looped in, briefed, and rallied to ship and support the software. On the surface, a software might seem deceivingly simple. However, there are many different things that go on in the background to create, continually update and support the product so that it gets better over time, something that’s automatically done for you if you decide to buy, versus building it internally.