All software choices fall somewhere on the build-buy spectrum, & all companies fall somewhere on the ‘tech company’ spectrum. A piece of technology’s ubiquity, price, and proximity to a company’s core competency all play a factor in where it fits on this spectrum.

In this article, you’ll learn about what factors go into a build or buy decision, so you can make a more informed choice that fits your company’s needs.

The far ends: clear buys and builds

On the far end of the “buy” spectrum is software that is relatively cheap and solves problems that most businesses have, like GSuite and Microsoft Office. It would not make any sense for, say, a logistics company to build a word processor.

On the other end of the spectrum, we have software that solves unique problems and adds business value. These are clear builds. If that same logistics company had a unique process that enabled them to process deliveries more efficiently, and therefore provide better rates to their customers, it would make sense to build software for their process, since an off-the-shelf solution by definition could not exist.

In the middle: consultingware and integrationware

In the middle we have solutions built on customization and integration.

Some companies sell “ consultingware “, software that has a cheap base price, which is then used as a platform for the company to build more expensive custom software on top of for you. This is what I did at my first salaried job after college. The company would sell $5,000/year licenses for a bare-bones platform. Then the salespeople would talk them into custom-built add-ons for an additional $25,000 – $50,000.

Next, is solutions built around integrating several other off-the-shelf solutions that can work together. Then, closer to building your own software, you build and own custom integrations that interact with an off-the-shelf solution in particular ways. Look at an agency like 6kites or neurored to see an example of a company that deals with this kind of work, which I’ll term “ integrationware.”

Both are a mix of buying something that already exists, and then “buying the building” by hiring a 3rd party to do additional work on top of that.

The key difference here is ownership of the software. In consultingware, the company maintains ownership of the product, and sells licenses with an audience of 1. With integrationware, you typically own part of the platform, which integrates with an external service.

At the ends of the spectrum, the decision is easy: It makes no sense to build your own generic solutions, and you can’t buy solutions that don’t exist.

Where things get interesting is in the middle, and deciding where in the middle you fall. It’s usually not a question of “build or buy” but how much of the solution needs to be built vs bought?

Example: Should a restaurant bake or buy dessert?

Imagine running a restaurant and deciding how you are going to serve dessert. You could buy pre-made cakes from the frozen food section. You could partner with a local bakery and sell their product. If you have in house baking expertise, you could buy eggs, flour, and sugar and bake them in-house. An extreme take on the “from scratch” cake would involve adding a farm to your restaurant, where you can raise egg-laying chickens and grow your own grain.

If you think that the last example is unrealistic, let me introduce you to the pizza farm.

Factors to consider:

Available Resources

When you have more internal IT expertise and less available cash, building solutions makes more sense. You’ll lean towards buying when the inverse is true. When you’re company doesn’t have the internal IT resources needed to build software, you either have to bring in outside agencies and contractors, or increase that competency by hiring new people.

Risk

When you buy software off the shelf, the most significant risk is the death of the vendor relationship. When you build software internally, the most significant risk is failure to launch. Once you buy an off the shelf solution, you have some vendor lock-in. That means you have taken on some risk with that vendor, and have to consider the possibility that one or more of the following possible:

• The vendor goes out of business.
• The vendor decides to stop supporting the software.
• The vendor is acquired, and the service agreement changes drastically.

You can avoid this by building software you have total ownership and control over, but that comes with not only costs, which we’ll get to in a bit, but also its own set of risks.

• The project is never finished.
• The project takes longer than expected.
• Requirements aren’t clear, and the project doesn’t deliver the results needed.

One puts the risk internally, the other puts the risk externally. Also consider that if you hire a 3rd party to build your internal tool, you can end up in a situation where you have the risk of both .

Total Cost of Ownership

This can be the most difficult one to determine. That’s one of the strengths of going with a pre-built solution, is that you know what you are getting and when you can get it. When building your own solution, both of these are known unknowns. While there are ways to reduce the risk and variance in a software project , you can’t fully eliminate those problems.

When you own your own software, there are some costs that may not be immediately apparent:

• Hosting
• Security
• Maintenance
• Backups
• Just to name a few

Bought solutions can also have some unpredictability in pricing. First, there is negotiating with the vendors, which could land you a deal based on how long sign up to use the service.

Then you have to consider the unit of measure that determines the price. For example, Slack bills on a per-user basis. How accurately can you estimate how many people be working at your company for six or twelve months from now? You probably have some idea, and can gauge how much it will cost. However, if the pricing unit of measure is something out of your control, like website traffic, you could end up with an unexpectedly high bill.

As a general rule, the cost of ownership of maintaining software that you actually own is going to be higher. But at some points, that may not be the case. You could end up paying for 100% of a solution where you only need 20% of the features. That coupled with the extra time trying to figure out how to get a generic solution to fit your specific requirements and processes.

Time to Launch

How quickly do you need a solution?

As a general rule, buying off-the-shelf software is faster than building something yourself. As another general principle, there is a time-value of software : Solutions you have today are more valuable than solutions you have tomorrow.

However, with building software, the time to value does not have to be binary. The software can deliver partial value over time if you are doing it right.

Accomplishing this requires a developer or team that understands the difference between building half-products and half-assed ones. Software is never done and typically turns into an infinite project, living as long as the business itself.

Scale matters here as well. Sometimes a script knocked out in a day can be more efficient than integrating a 3rd party tool that takes weeks of configuration and importing to start delivering value.

Core Competencies

The closer the solution aligns with your core competency, the more sense it makes to build something yourself.

How closely does the solution line up with your core competencies? Will building custom software give you a competitive advantage, and increase the value you can deliver to your customers? How quickly and with what quality can you actually build the thing? If you can answer yes to one or more of these, then you may have a case for building a custom solution.

For example: banks and telecom companies. They have unique needs, and building custom internal solutions make sense. But most companies have technology as part of their offering, so at some point, building your own tech is inevitable.

Business Processes

Your technology is only as good as your workflow.

How unique are your business processes? You have to have alignment with your processes, and commercial off-the-shelf tools. When building software, getting alignment should be easier, as you can make all of the design decisions.

If there are several off the shelf options available, and none of them match your business practices, that could be a sign of process smell. If everyone is doing everything differently than you and you cannot identify an advantage to your unique approach, then there may be room for optimization in your own processes.

Adopting a new tool alone can’t change your business processes, but it can help.

The scale of your company matters as well. The larger your company, the more complex building a solution is. When you are smaller and more niche, You can build products faster.

Before making a buy or build decision, consider how the software would affect your day-to-day processes.

Finally, tackling the decision

If you find yourself having this conversation at your company, that’s a good sign. It means that your organization doesn’t have “not invented here syndrome“, and that it is willing to look at multiple options for solutions.

The answer depends on your stockpile of resources and your risk tolerance. Do some homework and try to figure out what solutions are available, and what the total cost of ownership would be. Regardless of what direction you decide to move, these are typically decisions with real ramifications in your business. New technology requires integration and buy-in; you want to make sure you are making the right decision before moving forward. Here are some questions to ask yourself when considering whether or not to build or buy software:

• How much are we looking to invest in this solution?
• Do we have the IT resources in house to build and maintain a solution? If not, could we get them?
• Would the technology affect the value we deliver to customers? In what ways?
• How willing are we to change our processes to better fit into commercial off-the-shelf solutions?
• What is this solution going to look like in 12 months? How will it be better? Worse?
• How urgent is the problem?
• What features do we not need? How does an in-house half-product compare to a feature-rich generic solution?

The post How to decide when to build software vs. when to buy appeared first on Glenn Stovall.