At one time or another, we’ve all been faced with the age-old “build or buy” decision. Homeowners decide whether to paint their own living room or have a professional do it. Businesses decide whether to hire an in-house accountant or have an outside CPA manage their books.

In many cases, the “build or buy” decision is relatively minor, so if you make the wrong decision you can recover without too much trouble. When it comes to enterprise software, however, the stakes are very high. To build or buy enterprise software is a huge decision and has enormous ramifications. Making the wrong decision can cost millions of dollars, and months, if not years, of time. 

Opinions on this topic range from one end of the spectrum to the other, and there are valid arguments made on both sides. I fall into the “buy” camp, for sure. I do believe there are circumstances when “build” makes sense, but only after careful consideration. 

And speaking of considerations, here are a few to bear in mind when your organization is deciding between building or buying enterprise software. 

List the Requirements

It’s hard to make a good decision if you don’t have good information. Start by creating an exhaustive list of requirements. Get granular. Yes, it will take time, but it will be well worth the effort. 

I’m not a big fan of project management software applications, but a lot of people love them. I’m more of a spreadsheet guy. The tool you use isn’t as important as the thoroughness of the list. Creating a comprehensive list of requirements will help you tremendously. It will give you an invaluable perspective on your project, and help you decide if it makes sense to do it in-house, or not.

Ask the Hard Questions

Ask yourself the hard questions – especially the ones you don’t really want to ask because you know you won’t like the answer. 

Some of the questions you might want to begin with: 

• What business are we in?  (This is the most important question of all!)
  
  Choosing to develop an enterprise software solution in-house is essentially choosing to start a new software company. That company may only have one customer (you), but don’t presume you can treat an enterprise software solution like “just another” IT project. It’s a huge undertaking and it will require a lot of resources and support both during and after development.

• Is there a learning curve?
  
  The learning curve usually isn’t technical. Rather, it’s often business-related. Most internal IT departments have very talented software developers. The learning curve you need to consider is the problem you’re solving – the business solution for which you’re creating the enterprise software. Do you have both vertical and horizontal knowledge? Ask yourself honestly:  how long will it take to gain the knowledge you’ll need for your project?

• Do we have the bandwidth?
  
  I don’t know of many IT departments that have people sitting around with nothing on their plate. IT personnel are stretched thin, even in the best of times. You need to honestly consider how many developers, analysts, testers, scrum masters, and other people it will take to devote to your project. What will happen to the existing projects your team already has? Will they be delayed? What will that mean to your organization? These are tough but critical questions.

• What will it really cost?
  
  If we’re honest with ourselves, we know cost estimates are always too low – even when we do our best and take into account everything we can think of. The truth of the matter is, there’s always something we don’t think of and/or don’t plan on. In my 30-plus years of enterprise software development, a good rule of thumb is to triple the initial estimate.

• What if we miss our estimates on both cost and timing?
  
  What happens if you go over your cost estimates? What happens if you miss your deadlines for release dates? How does that impact the enterprise system itself? How does that impact other systems, departments, processes, and projects throughout the organization?

• Are we committed to continually maintain and update the system even after it’s “released”?
  
  A lot of organizations don’t think about the ongoing maintenance and continued development of the system. Getting that first release out the door seems like the end-all goal. Actually, it’s just the beginning. Where will your system be three, or five, or ten years after the initial release?
  
  This is perhaps the most common point of failure for in-house developed systems. That’s why I said choosing to build your own system is essentially creating a new business. If you don’t make plans to maintain and improve your solution over the long haul, it will quickly become outdated, and you’ll be right where you were when you started – only you will have spent tons of money and time.

Identify Potential Vendors

If you’ve asked yourself the hard questions and you feel confident in building a system on your own, you may be tempted to skip this part. 

That would be a mistake. 

Evaluating commercial vendors should be part of your due diligence. If your decision to build is the right one, evaluating vendors will help you feel more confident. If your decision to build is the wrong one, you will be so grateful you evaluated vendors. 

In addition to specific system requirements, here are a few things to think about:

• What are the key differentiators of each vendor?

• What do they offer that would be the most difficult to replicate if we built our own solution?

• What kind of reputation do they have in the market?

• Are they someone we could work with?

• Who are their existing customers? Do they have a proven track record?

• Are they financially stable?

Once you’ve gone through the full exercise of evaluating commercial vendors, add another column to your spreadsheet and place your in-house solution on the list – as if you were another vendor. Ask the same questions. Be just as hard on yourselves (if not harder) than you were on the commercial vendors. 

You may be surprised at what you find.

Be Realistic and Be Honest

Okay, you’ve created your list of requirements and carefully estimated what it would take to complete each item. You’ve evaluated commercial software vendors and added your own solution for comparison. 

Now what?

Before you go any further, take a breath. Remember, good decisions are based on good information. You now have good information. It’s time to make a good decision.

First, though, be careful. Too many of us make up our minds before we’ve honestly evaluated the information. Try to look at the information from an unbiased perspective. Speaking of unbiased perspectives, it would be a great idea to have a third party, like a consultant, look at your information and give their opinion.

The key is to be realistic (“Can we really do this? Do we really want to do this?”) and be honest (Can we truly do it better than a software company that specializes in this type of system?)

Summary

Over the course of 30-plus years in enterprise software, I’ve consulted numerous companies on whether to build or buy. As I said earlier, I do believe there are cases when it makes sense to build, but in my experience, companies are almost always better off buying.

Some organizations believe that building their own software gives them a competitive advantage – that they’ll be able to develop exactly what they want and no one else will have it. 

That was a valid argument twenty years ago, but not today.

Commercial solutions always have more functionality than in-house systems. And, with the availability of low-code configuration options, companies can have the best of both worlds. They can buy a fully functional, feature-rich commercial solution, and because of configuration capabilities, they can modify it to work just the way they want. 

Bottom line: Create a complete list of requirements. Ask the hard questions. Evaluate the commercial vendors in the market. Finally, and most importantly, be realistic and honest with yourself. 

If you do all that, you’ll make the right decision.