At Automattic and now at Help Scout I’ve been involved in several discussions about the merits of building something internally vs paying for a third party SaaS tool or plugin. Examples include the internal analytics platform Automattic (which we wound up building ourselves) and a business intelligence tool at Help Scout (which we wound up buying).

If you’re lucky it will be an easy decision, but more often than not there will be pros and cons to both approaches that you’ll have to weigh. Some of the factors include:

Do you have the engineering resources and know-how to build it? If not, you’ll obviously have to buy.

How much time will it take to build? As anyone who has built software knows, estimating how much time it will take to “complete” is often incredibly difficult. A one month project could easily turn into four after all is said and done. The more complex the project and the longer it will take to build, the more you should lean towards buying.

How much does it cost to buy? The cheaper it is the more it makes sense to buy.

How much will it cost to build? At first this might seem like $0, but engineers are expensive. A developer making $120K/year might be $180K/year fully loaded (with benefits, taxes, etc) or $15K/month. Several developers spending a month on a project can easily cost tens of thousands of dollars. And that’s not even counting PMs, designers, and anyone else involved in the project. It’s tempting to think “we have to pay them anyway so it doesn’t really cost us that”, but it’s not so simple once you consider what other revenue-generating projects they could be working on instead (and you don’t have to employ them anyway). There’s a real opportunity cost to building something internally.

Does the thing you’ll buy meet all of your requirements? If it’s critical that the software do something and the SaaS you’re considering doesn’t do it, you’ll probably need to build. However, you might be better off paying for a tool that is 90% of what you think you need vs spending weeks or months building something that might be 100%.

What other capabilities does the tool you’ll buy provide? While you might be able to build something that meets your minumum requirements, a tool you buy is likely going to do a lot more than the minimum. You may not think you need those extra features now, but there’s a good chance that you will later. At that point you might have little choice but to keep iterating on what you’ve built which can easily extend the duration of a project.

Is it important to own the data? Third party tools will likely collect user data which may be a concern both from privacy and analysis perspectives.

How likely is it that the third party solution will exist in 5 years? And are there alternatives you could switch to if that hot-new-startup you pay for shuts their doors in six months?

Are you building this as a long term investment? When we were considering whether to buy or build Automattic’s internal analytics platform one of the factors was that we planned on Automattic existing in 10, 20+ years so it made sense to invest time building something that we could use for the long haul. Be skeptical with this one though: while we might hope that whatever we’re working on now will exist in 20 years, the reality is that it probably won’t.

I usually default to buy unless there is a compelling reason to build. In my experience software usually takes much longer to build than initially expected so it winds up making more sense to pay for a 90% solution that you can have immediately and devote those engineering resources to the core business. But again, it’s often not so simple in practice and there can be reasons to build instead (full control over the features and design, ownership of the data, cost, etc).

I’d love to hear about your experience buying vs building. Was there ever a time you built something that you later regretted or vice versa?