Pros and Cons of Using Third Party Applications

Using LinkedIn, I recently asked the following question (see below) about the 'buy or build' issue:



Among the replies I received, the best came from one of our developers, Nolan Caudill. One of his initial comments essentially touched upon what I wrote about when I mentioned using Google Maps:

"With grabbing a third-party app, especially with open source projects, you are leveraging the expertise and testing abilities of people that you don't have to pay. And with popular open-source projects, you probably have had hundreds to thousands of people testing the software and fixing bugs. That's huge."

He's right- huge is definitely the right word. Huge, as in the multitude of developers out there refining the tool you've adopted, and in terms of the time and cash you save by not assembling a team to build it yourself. Nolan went on to touch on another aspect of adopting a third-party application or tool that is probably even more important than the initial considerations I've noted so far:

"Another big issue is maintenance. Building the software may only take a month, but you're going to support it for much longer. So whenever discussions arise about building software, the phrase should always be turned into 'building and maintaining' software. That almost always puts the software in a different light. If it's proprietary and you have a bug, you have to fix it. If you want a new feature, you have to build it. If a client has a question, you have to answer it. Also, you have the ominous software "bus factor." What if your lead developer got hit by a bus, or more likely, changed jobs? "

All great points. The bottom line is that when adopting a solidly developed application, you aren't just getting something that enables you to check a requirement off your list, you're also getting the benefit of an entire team's expertise and effort, both initially and long-term.

So far, the “buy” approach is looking pretty good, but it's not always going to be the right choice. Many of our clients have particular functionality requirements that are extremely specific to how they do business. In many cases, the types of business logic needed might actually require us to build some functionality from scratch that is similar to something already out there but not customizable in the way we need it to be. I'll note some examples a bit later that will help to clarify this point.   next >