Over a million developers have joined DZone.

To Develop or to Buy Software

DZone 's Guide to

To Develop or to Buy Software

Take a look at the business side’s perspective of evaluating whether to build or buy software from the head of development at dinCloud.

· DevOps Zone ·
Free Resource

I tapped Tahir Malik, dinCloud’s head of development, for some perspective on build versus buy because I believe it’s helpful for developers to understand the evaluation process.

Organizations that have their own development and R&D teams often run into the conundrum of whether to acquire a third-party tool or to develop their own intellectual property for the purpose of advancing their operational capabilities or upgrading their business offerings. The decision is never easy and relies heavily on multiple situational and structural factors. In this article, I have highlighted the benefits and drawbacks of both: purchasing your tool from a third party vendor and developing your own product.

Acquiring Third-Party-Software


  • Immediate Deployment - If you are constrained on time, a solution that is available in the market may be the way to go since it is already developed as per prevailing industry standards, and may be immediately deployed within your environment (and usually without a lot of complications).

  • Integration Support - Integrating the product into your environment becomes convenient as the vendor provides you with the required support to do so. Your teams do not have to spend countless hours determining how the process will be conducted, as the vendor’s product specialists are there to guide you throughout the implementation process.

  • Post Implementation Support - Generally, most vendors offer support for their tool post implementation as well. Again, your teams do not have to waste hours upon hours attempting to understand the product at the code level. If any issues arise, you can immediately reach out to the vendor who resolves the issues for you.

  • Faster Time to Market - Quicker deployment and integration of the tool results in an increased efficiency with which your operations are updated and upgraded, or your product is released to the market. Adopting a third party support tool is especially beneficial when time is of the essence and you wish to stay ahead of your competition with an upgrade to an existing offering.


  • Impact on Cost - Purchasing these tools adds to the cost associated with the production cost of your offering. In today’s competitive world, an increased product price may result in customer churn. If however the price is not increased, you end up losing per unit profit. Therefore, a detailed analysis needs to be conducted to understand if the functionalities being added to your product by the adoption of the tool will be attractive enough to bring in new business.

  • Customization Limitations - Any software designed by a third party vendor will be focused towards certain operations supposed to perform in such a fashion that it may be integrated by organizations with varying architectures. The manufacturers of the software thus keep its structure generic. This limits the amount of customization that may be done with the product once it has been integrated with your environment. There would a number of things that you would be able to change within the tool to make it operate according to your existing processes, but for others, you will need to improvise or find a workaround.

  • Limited Code Knowledge - Your development team will have limited knowledge of how the tool functions and will, therefore, be dependent upon the support offered by the vendor, should any issues arise. Although support may be readily available, reaching out to them increases the resolution time of the issue compared to if the tool was developed in-house.

Developing Your Own Intellectual Property


  • Localized Product - One of the biggest advantages of building your own tool is that it is entirely localized and customized according to your environment. Your team can design the tool exactly as per the physical and virtual capabilities of your organization, and may continually upgrade it, whenever required.

  • Limited Upgrade Cost - The cost of upgrading the software, when required, is negligible, and is only in terms of man-hours spent, compared to upgrading a tool acquired through a third party vendor. Furthermore, it is far easier to upgrade a tool that has been developed in-house as your team has full documentation of the areas that would require changes to incorporate upgrades.

  • Immediate Support Available - Since the tool has been developed by your own team, immediate support, when required, is readily available, and is free of any associated costs as well.

  • Organizational Asset - The in-house developed tool becomes your intellectual property and asset. As such, it adds significantly to the net worth of your organization.

  • No Licensing Costs - Since you developed the tool, there are no associated recurring licensing costs that dry out your profits.

  • Drawbacks

  • Time Consuming Effort - Designing a tool from scratch consumes time, especially if your resources are not very well seasoned. Although you do get an end product that is made to fit, several man-hours will have to be spent on its development, depending upon the nature and complexity of the tool.

  • Possible Training Cost - There may be some additional expenses as your development team may require training on the technology being used or developed.

  • Time to Market - The product you develop will need to be thoroughly and vigorously tested, and builds need to be sent back to development again, and after with reported bugs. The entire process of testing and QA adds to the time it would take to market your product, or improve your operations.

At the end of the day, as you look to move up the career ladder, understanding the criteria, and the pros and cons, will help you become a more sophisticated manager of technical resources. I have found that building a product you can find off the shelf results in a “catch up” period and longer time to market, which is offset by a potentially lower cost if it is being done in-house. If you are contracting the development work, then you are at the mercy of the contractor.

I recommend buying products that are on the market, then customizing them and developing them further with capabilities needed to distinguish your company or provide value-add as part of the company’s intellectual property.

deployment ,intellectual property ,enterprise ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}