Build vs. buy: know what you need, and know what you want

Making build vs. buy decisions is a pretty tough assignment the first time you do it, and it’s really hard to do right.

Many times, the lure of shiny vendors who give us slick sales pitches and cool things we hadn’t thought of, can cause us to lose sight of the benefits of rolling our own solution. Other times, if we’re looking at something that’s fun and interesting to build we can end up discarding the benefits of buying in.

These decisions are important, as building when we should buy can leave us lagging behind and fighting against feature debt and maintenance overheads. Conversely, buying the wrong thing can leave us fighting against something that doesn’t do what we need and is hard to work with. The negatives here aren’t just financial or reduced productivity, they also manifest in your team culture as frustration points, impacting your team’s motivation and, ultimately, retention. Equally bad, you can get yourself into analysis paralysis and lose out just by not making a decision.

I’ve found that it’s best to structure these decisions into phases. If you want to be able to move the decision forwards successfully, and in a timely manner, keeping each phase distinct will help to keep people focused on the right tasks to keep the process moving, and frame conversations in the right way. To do that you’ll need to know what you need, know how the options stack up, and then make the best decision based on that information.

Make a wish list

Knowing your must-have requirements, things you really want, and things that would be nice at the start of this process makes sure you’re all starting with a shared marker for success. It helps you pull out key features (or lack thereof) hidden in the small print, and that you’re evaluating your options fairly. Plenty of times the slick sales pitch will gloss over deficiencies in a bought solution; your internal build option almost certainly won’t have that presentation! 

The criteria here have to be really succinct and clear; the people evaluating the various options, or trying to make a decent estimate of the build, have to have a very clear understanding of what they need to make work. Wherever possible, those criteria should be a yes/no answer. While the occasional ‘maybe’ is okay, if you’ve got a scoresheet full of them – or worse, pages of opinion prose – you’re going to find it much harder to make a decision. Those non-explicit criteria will then be even harder for whoever’s looking at the build to come up with a decent estimate. We all know how hard it is to estimate big software projects.

Interlude: Can we even build it?

At this point, it might be worth doing a quick thought exercise to see if a build is feasible. Does your team have the capacity and/or skills to build it? Can you acquire them in a predictable way? If you’re not going to be able to build your thing, build it well, and/or maintain it, then you’re much better off buying. From this point on, people are going to start getting emotionally invested; there’s a risk those looking at the build option are about to embark on some discovery or prototyping work that doesn’t get used. The danger around not setting this up right is people feeling like their time and effort have been ‘wasted’ when nothing could be further from the truth. Exploring your options properly shouldn’t be wasted work, but if your team doesn’t understand the terms under which they’re working, they can easily feel like that.

Find your vendors and keep a scoresheet

Now the fun begins: you need to find out what your options are. There are loads of resources around for finding out which vendors are good, bad, and ugly in the space you’re investigating. However you find them, it’s important that you get more than one buy option, even if there’s only one apparently serious vendor in the space. I’m sure there could be books dedicated to sourcing good vendors, but remember your list is never going to be perfect and there’s every chance you’ll stumble across one just after you’ve made your decision. You’ll almost never have a perfect picture; the aim is to get the best possible picture in a reasonable timeframe.

As you come across vendors, keep a very clear scoresheet for your buy options, and get as good an estimate as possible for your build. This will help you do a few things, including helping you screen out a bunch of vendors without having to go into in-depth conversations with their sales teams. For those that look like they might be the real deal, try and get trials – there’s no substitute for actually using the thing and being able to poke around behind the sales pitch. 

Once you’ve got your compiled scoresheet and high-level build estimate then you’re ready to move on to the decision phase. It’s a good idea to have a known ‘last call’ date here so everyone knows when they need to get their preferred vendor on the scoresheet.

Making the decision

Now you’re armed with the data, you’re in a position to make the decision. There are reams of literature out there on decision-making and how to do it well.

Will a build let you differentiate?

This is one of the most important things to consider if, when looking at your scoresheet, the vendors don’t quite do what you need or want – it means you have an opportunity to differentiate. If you can do everything you want to do with something off-the-shelf then what are the value adds (or subtracts) of building? There are some places where this is really easy, most businesses these days will not maintain a data center better than AWS, Microsoft, or Google. I can’t think of many examples of when a content management system is a differentiator unless you’re a company that builds content management systems. But there are more borderline cases, and if you’re seeing gaps in your scoresheet, you’ve probably got an opportunity.

Can you get to parity and stay there?

If you choose to build, will you build a quality product that matches the functionality of your candidate vendors, and then keep pace, or differentiate? If you’ve got one differential feature you think you can build, can you use a third-party tool as a base and build a plugin or extension? If building is going to mean you always lag behind, it’s unlikely to be a good choice. 

A word on relative cost

This can be one of the hardest factors to quantify. If you’re evaluating the cost of licenses or maintenance packages vs. build cost, you may not know how much it’s going to cost to build. You won’t get a direct comparison, mainly because you’re comparing a solid, operational expenditure against the opportunity cost of using your team to build something else. So, my evaluation criteria here are: are we going to get enough benefit from a buy to justify the cost? And, is this the thing I’d get the most value out of my team building?

Can you change your mind?

If you make one decision, can you switch back easily? It might be that running out an implementation using prebuilt software while you build is a good way to get an iteration to market that you can build on later. Can you use a bought solution as a springboard to a differential built product later? How long will you be locked into a contract? Almost invariably, if you decide to build and then bail out if it turns out to be harder than you thought, you will burn some in your team. This shouldn’t mean you only take the reversible option, but, if it’s a tight decision, and there’s an easy-to-reverse option, that can be a tiebreaker.

Conclusion

Build vs. buy decisions are hard, and it’s easy to lose focus and direction when making them. By following a staged process where you define what you’re looking for, going and finding out what your options are, evaluating against clear criteria, and finally gathering all of that information to make a decision, you’re more likely to come out with a good, unbiased decision. My last piece of advice is to remember that there’s no absolute ‘right’ answer – all you can do is make the best decision with the information you have.