Organizations have always battled with the question of whether to develop software in-house or purchase off-the-shelf. This debate is all the more relevant in modern software development organizations DevOps, where there’s a constant balancing act between helpful functionality, time constraints, and cost-effectiveness.
On the other hand, as more people learn to code themselves – and to use AI-assisted coding methods or even no-code software building tools – it’s easier than ever before for teams to build their own apps.
The situation is slightly different when it comes to the DevOps tech stack, as the DevOps team is uniquely capable of building a customized and effective toolchain. However, under many circumstances, it’s still more cost-effective or time-efficient to buy a solution – even for DevOps purposes.
The resources needed to build custom tools can vary considerably depending on the scope of work involved, and if your company already employs a team of developers and engineers, then this lowers the investment required.
However, it still takes significant time to build a DevOps tool, with both in-house and outsourced development teams costing hundreds of thousands of dollars per year. Even an optimistic estimate would see organizations spending over $50,000 to build a tool and over $10,000 annually for ongoing maintenance.
This article will explore the build vs. buy dilemma in DevOps and try to find a balance that maximizes efficiency, flexibility, and return on investment.
Build vs. Buy for Infrastructure-as-Code
Infrastructure-as-code (IaC) is becoming a must-have for organizations to maximize the efficiency of their cloud and on-premise infrastructure.
However, it’s still relatively new, and many DevOps teams lack the expertise and experience working with platforms like Terraform, Ansible, and OpenTofu. In situations where that is the case, buying an off-the-shelf product with all the essential features plus dedicated support enables DevOps teams to adopt IaC quickly.
The main problem with an in-house solution is that it takes a relatively long time to develop, and despite this, it will have a minimal feature set that might take years to blossom.
When using an existing IaC solution, on the other hand, customization limitations are hardly noticeable, as most IaC vendors now offer detailed configuration options and support for custom modules.
Financially, buying also makes more sense, regardless of team size and the complexity of your infrastructure. Using the Terraform subscription tiers as reference, it would cost $3,600 per year for a team of 10 developers. While this is no small sum, it’s nothing compared to the salaries of the developers needed to write and maintain a custom solution.
The cost savings also translate to larger teams, where cumulative subscription fees remain significantly lower than the escalating expenses of developing and maintaining a custom solution.
Build vs. Buy for Platform Engineering
As part of DevOps, platform engineering focuses on delivering curated, self-service internal platforms that streamline software delivery. A digital platform provides a unified environment where developers can easily access the necessary tools, pipelines, and infrastructure. Engineering platforms that can be purchased are often called platform-as-a-service (PaaS).
Unlike IaC, engineering platforms are more expensive and take longer to build, so building one in-house requires a significant time and financial investment, even for a small DevOps team. However, enterprises may find that such an investment is worthy, as it allows for complete customization and alignment with their unique workflows and strategic objectives.
PaaS offerings do come with a large set of out-of-the box features, but they often lack the customization capabilities to fully tailor the solution for the needs of a large DevOps team.
Smaller teams, on the other hand, may benefit more from a PaaS solution due to their smaller scale and simpler workflows that don’t require much customization.
Build vs. Buy for Code Management
Code management includes the practices and tools that enable teams to efficiently handle source code throughout the software development lifecycle. The most common approach for developers is using Github, which provides comprehensive version control, collaboration features, and integrated CI/CD workflows.
Github has a tiered price structure that accommodates varying team sizes and needs. Github Team costs $21 per user per month, while larger teams may need Github Enterprise, which sits at $100 per user per month.
In addition to the per-seat subscription model, GIthub Actions functions on a pay-as-you-go model, charging based on the time worked. Teams need to be careful with this approach, because actions are counted up to a minute, so if workflows contain numerous short-lived tasks, the costs can accumulate quickly.
An alternative would be creating an in-house solution. However, it is difficult to find a use case where such an endeavor makes sense, even for large enterprises. The cost of development, maintenance, and integration are too high, while alternatives like Github work great and are relatively cheap.
Build vs. Buy for Scrum Management
For agile projects, scrum tools are key players in ensuring streamlined collaboration and on-time delivery. The most important factors when choosing whether to buy a commercial Scrum solution or build one have to do with the desired level of customization and ability to integrate with existing workflows.
Ready-made tools like Jira or Trello are highly popular and affordable, and have many functionalities that are ideal for agile project management. These include sprint planning, backlog management, charting, and integrations with other popular tools.
Buying is significantly more cost-effective, as a subscription for tools like Jira and Trello cost $10-20 a user per month. The only exception would be if DevOps needs many additional features, plugins, or integrations that can quickly add up costs for licensing.
Building a scrum management tool would still be substantially more expensive and complicated, but it could be worth it because of the long-term cost savings and ability to fully customize the tool.
Bringing It All Together: A Decision-Making Roadmap
Deciding on which combination of custom-built and off-the-shelf products you want to adopt can feel a bit overwhelming. Yet, the core considerations are similar across the core DevOps domains, from IaC to Scrum management.
Here is a step-by-step decision-making roadmap you can follow to make build vs. buy decisions with better clarity:
1. Identify your strategic priorities. Determine whether speed to market or long-term flexibility is more important. Also, consider whether the function is a core differentiator for your organization or just a nice-to-have.
2. Evaluate your team’s expertise. This might be the most important part, as without enough skills and experience, any in-house solution will quickly become unmanageable.
3. Determine the costs across the full lifecycle. Look beyond the initial development or licensing fees and also consider the costs for maintenance and support.
4. Consider compliance requirements. Pre-certified commercial solutions significantly simplify any compliance or security requirements. If you decide to go with an in-house tool, consider that you will have to plan to incorporate the necessary regulatory and security controls.
5. Pilot and gather feedback. Before you go all-in on a certain approach, it’s better to first run a small-scale test to confirm feasibility and user acceptance. Stakeholder input is key to ensure the long-term success of the implementation, and this is true whether you’re building or buying.
Conclusion
The mainstream response to build vs. buy decisions is almost always “it depends,” and that holds for DevOps as well. The right choice hinges on what your company’s primary business is and whether you have the financial resources and vision to function as a software development entity alongside your core operations.
