4 Key Factors to Determine whether to Build or Buy Software

When faced with a problem that software will solve, the classic tech dilemma is whether to build or buy the solution. This happens to large agencies, new startups, and independent freelancers alike.

As the decision-maker, it's really easy to get pigeon-holed into thinking about only one piece of the pie -- i.e. It's cheaper to build, so we're going to build it. But it takes stepping back and looking at the entire picture to come to an informed and strategic decision.

That's why, when making a build-v-buy decision, I use four key factors to determine the best path forward. (I've come up with these factors after making a number of decisions that have come back to bite me.) The factors are:

1. Comparing costs
2. Evaluating experience
3. Claiming expertise
4. Ownership lifecycle

Let's dive into each one.

01: Financial Comparison

The financial comparison is the obvious one, and it's the first thing most jump to when comparing buy and build solutions. And it makes sense -- it's an objective measuring tool.

Typically the cost of purchased solutions are straightforward and known (think: subscriptions, license fees, etc.). There are some cases where cost may be based on scale or usage and may require making an estimate. But for the most part, costs for purchased solutions tend to be known.

Calculating the self-built solution takes considering the cost of the time to plan, build, and maintain the solution, minus any efficiencies gained. Even if the self-built solution doesn't cost money (e.g. a side project for the weekends), it's beneficial to think of time as money and evaluate anyone who is going to work on the project appropriately. And remember, developers are notorious for underestimating the time something will take! Take their initial estimate for the build, double it, and then consider supporting it over time (more on this later).

Last, know that no solution lasts forever. It's wise to choose a reasonable time period in which to compare the cost of the solutions. This puts the solution options on level ground by considering the maintenance and support required over time.

Quick Example: Let's say I can build or buy a CMS for my new website, which I want to last for three years. The buy solution means using a hosted, third-party system, and will run me about $100 per month, or $3.6 over three years. To build it myself would take 100 hours, I think (so, really it'll be more like 200), and I'll spend 25% of the initial build (50 hours x 3 years = 150 additional hours) maintaining and supporting it each year. If my time is worth $100 per hour, that's $35k.

So, in this example, the buy solution is about 10% the cost of the build solution. And yet, it's easy to say that if I am building the thing yourself, it doesn't technically cost any money, so really the purchased solution is more expensive. I encourage you to stay away from this line of thinking. While technically true, your time is valuable and deserves to be evaluated as such. If you're not spending those 350 hours building and supporting a CMS that's time you can spend on other projects (or just having fun, because that's important, too).

02: Value of Experience

While financial comparisons can provide an ability to be objective, there is an incalculable value in the experience gained from any solution. When building, everyone involved may learn a new set of skills out of a necessity to build and support the project. And yet, sometimes buying can also provide experiential benefits. If you're considering purchasing software that is used elsewhere in the industry, it can be beneficial to use your purchase as the excuse for learning how to work with it, which you can then use on other personal or client projects.

Continuing with the CMS example, is there more value in learning how to work with a third-party system so I can recommend that to my clients or so I can be prepared when a client requests using that tool? Or is there more value in learning how to build a CMS so I can be the expert when it comes to solving future content management problems?

03: Ubiquitous Expertise

But here's the thing -- the thing I've always struggled with the most -- no matter how you evaluated the experience of each solution, you can't be an expert at everything. As the builder and maintainer of a solution, you'll grow to be an expert over time. You'll have to be to own the solution well.

Choosing build a few times for a few problems is perfectly fine. It's possible to be really good at a few things. But as more problems (because there's always a new problem) require more solutions, the more you choose build, the more you have to be an expert in more stuff, and there's a tipping point as to when that's not effective.

Said another way, when someone offers a solution for purchase, they are claiming to be the expert in the problem area and for the solution. When you choose to build, you're saying you can do that better -- you either know or can learn more about the problem area, and you can build a solution that is more effective than you. Often there is a significant amount of time and energy needed to get to a level at which you can provide a better solution than those offering it to you.

Think about the CMS solution. If I build my own, I'll have the ability to serve dozens or hundreds of clients with it. I'll learn a lot from each client that will inform how the product should change to serve future clients. But the CMS vendor offering the product has thousands of customers, many of whom they interact with on a daily basis. And they have a team that is constantly working to make the CMS better, whereas I'm only going to work on my product when I have a need. Unless I'm prepared to turn my solution into a product and serve hundreds to thousands with it, I'm never going to be more of an expert than those that work on their solution and gain feedback every single day.

Cost aside, it is very often in the best interest of the project to let the experts of the generic solution remain the experts of the solution, so you (or your team that is solving the issue) can focus your efforts on how to best solve your unique situation.

04: Solution Lifecycle

As hinted above, building a solution isn't just building a solution. There's support and maintenance of that solution if it's going to perform well enough and hold up over time. There will be bugs to fix, features to add, customers to calm, etc. All of that can become time-consuming (i.e. expensive), depending on how you plan to distribute.

For example, open-source software that picks up popularity can be a huge time-suck to manage. The goal for open-source is that the community contributes to it, and that takes time to manage. Still, offering a paid product is even more work, since you then become financially and legally obligated to provide support and maintenance to and for your clients.

And even if you are just managing a solution for an internal team. Clients are still clients, no matter the building in which they sit. And if you want those clients to be happy, there's time (which means money!) to be spent to keep them that way.

Summary

To bring it all back together, you can use the four factors to ask yourself a series of questions prior to making the leap to build or buy any particular solution:

1. How much will each potential solution cost over the expected lifespan of the solution?
2. To what extent does each potential solution provide intrinsic value to the stakeholders who will employ it and the team that will build and maintain it?
3. Is it worth the time/money to become an expert in the problem area enough to be able to support the solution? Or is it better to leave the broad knowledge on the solution to the current experts so focus can remain on the specific problem.
4. Are you (or your team) prepared to spend the time and money to support, maintain, and enhance the solution?

In my early years of software development, I chose build a lot. A lot. Shoot, I iterated on a content management system for more than five years. And I wouldn't change it. My time wasn't worth much in those years, and the value I gained from thinking and rethinking through how to organize and deliver content has helped shaped the future of development for me.

Today I'm still faced with solving CMS-related issues and I buy almost every time. My time is worth a lot more now, not only dollar-for-dollar, but there's also more asking for that time (projects, colleagues, clients, family, hobbies). While I still work on side projects, I focus my efforts to solving each project specifically because I know I don't have the time to support an ongoing solution.

That being said, there are often little problems in every project for which I have to considering building or buying. For example, I wanted to add searching ability to this site, but I didn't know how much people would use it. A more comprehensive solution would have come with using something like Algolia or AWS CloudSearch. But I didn't know how much it would be used and I didn't really want to pay for it, so I chose to roll my own search solution using Lunr.js, and it's worked perfectly fine for 4+ years.

There is no right answer when it comes to building or buying a solution to a problem. But it's imperative to weigh all options thoroughly to ensure the decision will hold up over time.

And remember, there's always going to be a new problem to solve. If you make the wrong choice today, you get to learn and grow from it. And if you're fortunate enough to make a good choice, well, you're going to have to do it again soon, so don't get too comfortable.