Once, ‘building your own’ was the only way to get new software. Few options (other than monolithic solutions) were available for critical platform functions, and if you had specific tech stack or use case needs, coding it yourself became a given, not a choice. Fast forward and there’s an explosion of solutions available – big and small – which makes the age-old question of ‘build versus buy software’ increasingly tricky for engineers and leaders to resolve.
The real dilemma with the build or buy software choice is that on the surface it appears to be binary. In fact, it’s a nuanced, multifaceted decision. Likewise, your choice not only produces radically different outcomes in the near, but also the distant future. That’s a lot of variables.
Add to that rapidly changing economies, technology and market demands. That's yet more variables that can make weighing the build vs buy software pros and cons even harder, because most of those challenges and opportunities are yet to show themselves.
So your final decision needs to facilitate a plastic, not static, tech stack… and future.
But how do you do that?
The build vs buy software debate
Let’s start with the fundamentals. Crucially, there’s no one-size-fits-all answer. Plus, it’s important to transcend your biases and objectively examine the two distinct paths (although there’s now three – more on that later).
Additionally, the build or buy software debate doesn’t just influence the overall project you're working on – it also impacts the little, individual choices made throughout development. How’s that? It can matter whether the individual components, within the project, are built or bought.
And while your final choice should consider many of the things discussed in upcoming sections, the three big requirements of a project (cost, time, resources) have an outsized impact – so if using a package helps make development more efficient, productive or faster, don’t be afraid to buy. On the other hand, if a package forces you to adjust or limit your requirements, building may be a better fit.
Build or buy software: what does it mean?
Next, let’s clarify what we’re discussing: what does ‘build’ entail, what does ‘buy’ mean and what’s this third option?
1. Build software
Generally, building software results in a tailored solution with a unique feature-set.
To ‘build’ software, you’re taking a list of requirements, then scoping and building custom software from the ground up that meets both your basic and custom requirements.
Custom built software usually fits perfectly into your existing/legacy tech stack and doesn't conflict with or disrupt existing business processes and tools. The code your dev team creates is your property, so in the long term, you can turn your solution into a commercial product and sell it to others.
2. Buy software
Buying offers a ready-made solution, with often limited options to modify or customize.
When you ‘buy’ software, it generally refers to either buying a third-party package to include in your project (to meet certain requirements), or using an open source package. Implementation of a ready-made package accesses third-party specialization and generally doesn't take much time, so it can bring value almost immediately.
Note: For simplicity, this article uses ‘buy’ to reference the incorporation of any third-party package into your project, whether it has a direct monetary cost (proprietary purchase, SaaS subscription) or no cost (open source).
3. Hybrid buy-and-assemble components
A buy-and-assemble component approach minimizes custom-build outside a company’s expertise, facilitates continuous deployment from a reusable stack and opens the door to some customization.
Some companies split the difference between build and buy, in favor of a hybrid approach, where they buy a component or bigger solution and then build on it or create custom functions that fit their unique needs.
Even though this third option has been available for several decades, its popularity has grown from the explosion in software availability – specifically the proliferation of low-code/no-code options. This hybrid buy-and-assemble approach, focuses on the integration of components that tap into the horsepower behind third-party specialization, it empowers developers to focus on what they do (and know) best, and delivers nimbleness to the company to move beyond productivity obstacles.
The third-party buy-assemble package could be:
- A small component – e.g: something for date formatting
- A larger component – e.g: a WYSIWYG editor, like TinyMCE
Buying-and-assembling third-party components that are proven and trusted, scales a new way of developing software.
Note: For simplicity, this article uses ‘buy-and-assemble’ to reference the incorporation of any third-party package into your project, whether it has a direct monetary cost (proprietary purchase, SaaS subscription) or no cost (open source).
McKinsey has dubbed the buy-and-assemble approach a ‘digital factory’, where a company:
“...brings together the skills, processes, and inputs required to produce high-quality outputs. […] The best digital factories can put a new product or customer experience into production in as little as ten weeks. The innovation can then be introduced and scaled up across the business in eight to 12 months.”
All sides of the build vs buy software debate
If you’re a developer reading this, you’ll get it: building things is fun. Nothing more needs to be said. And having total control and ownership over the code, data and ongoing roadmap gives you great power over the future. But as straightforward as the choice may seem, there are times when building isn’t the best option – especially when you’re unnecessarily building.
If there are well established reliable options available to buy, subscribe to or buy-and-assemble, building your own software can be wasteful.
It can take your teams’ focus off key project and company goals, and creates additional coding work that could have been avoided. In this scenario, buying a ready-made package or perhaps considering buy-and-assemble components that allow you to create a flexible, plastic tech stack, may allow you to keep better on track.
Example of third-party component buy-and-assemble
A third-party package can make parts of your project easier, as well as giving you extras – in terms of features, support, longevity, and even file size, that help you scale in the future. It also highlights that having your best devs – or new-hire specialists – spend countless hours architecting something that already exists, just to say it’s your own code, could be wasteful.
An experienced, third-party vendor has likely already solved the same problems your team will hit during development. By tapping into that expertise, your devs and users benefit from the established best practices they employ during their development cycles and shortcut your launch timeline.
One component where it’s been proven to be more cost effective to buy-and-assemble, is a third-party rich text editor that gives you full code access, to customize and control your end product.
Rich text editors (RTEs) are one of the highest-risk areas for both cost and development time overruns. Feature and system complexities are notoriously underestimated, iterative bugs demand constant attention, and WFH work is forcing rapid-fire evolutions and adaptations in all browser based editors.
An in-house built RTE may deliver all your customisations. But it absolutely also adds greater risk and uncertainty into a total cost of ownership (TCO) equation that’s already fraught with technical complexities and unknowns. Because RTEs are in an ongoing state of evolution,
buying-and-assembling this reusable software component is an agile and smart solution, versus buying or building software.
Get more insights in
The Great Debate: Buy vs Build Rich Text Editors READ OR DOWNLOAD THE WHITE PAPER
Build or buy software: factors to consider
Before exploring the pros and cons, it’s useful to understand that the build vs buy software debate covers a lot of ground. Some thought starters:
- What problem are you trying to solve?
- Which path solves your problem best, without introducing additional risks, resources or complications?
- What’s the cost difference for the business between building and buying?
- Consider the up-front costs, but also the on-going costs
- What are your development team’s strengths, weaknesses and areas of expertise?
- Will a new project distract them or drain resources away from achieving the strategic focus of the business?
The next step is to contextualize your answers in relation to your business, because each company’s team, resources and goals are different. Consider what currently works well and what needs to be improved – including your team’s track record on building outside their zone of genius and your current hardware/software systems.
Generally, the top three considerations when deciding between building or buying software are:
- Cost/budget
- Time
- Expertise/resources
Other considerations to research (covered later):
- Complexity/Reinvention
- Support/maintenance
- Quality of package
- Customization/scalability
- Coherence with existing tech stack
- Competitive advantage
- License limitations
Build vs buy software pros and cons
For many dev teams, “Lets build!” is the automatic answer to this age-old question. Easy access to online training and information, open source options, and no-code/low-code software have made it easy for almost anyone to build their own solutions.
But is that the best decision over the life of the codebase?
Build vs Buy Software Pros and Cons |
||
Pros |
Cons |
|
|
Building software: Custom |
|
|
|
Buying software: Ready-made |
|
|
|
Hybrid buy-and-assemble components: Out-of-the-box components with customisation options |
|
|
8 arguments for the build or buy software debate
Because of its magnitude and potential costs, weighing the decision is a big one. To ensure a successful choice is made, take your time planning, researching, and assessing your options.
1. Cost
Yes, building your own software is a big upfront investment plus there’s ongoing maintenance costs. But third-party packages come with costs too. There’s monthly/yearly fees to keep using it, and while some features are no cost, others require an on-going commercial agreement.
Another cost consideration is ongoing maintenance and feature extensions.
In some components, like rich text editors, these costs can run into the millions. For example, building an advanced copy-paste feature, doesn’t start and end with the development and building phase. It also requires ongoing maintenance and extensibility work through the life of the feature. All of these complexities and interactions need to be factored into the total cost of ownership (TCO) of the plugin.
2. Reinvention
When you have an incredibly unique or business-specific workflow or requirement, building may be the best choice. But when a particular requirement is rather common – maybe something like date manipulation in JavaScript – using an existing library such as day.js may be easier, so you can keep yourself focused on the project requirements.
There’s no point reinventing the wheel when existing packages can do it for you.
3. Resources/expertise
While a business leader may have brilliant ideas about what their dev team can do, the bigger question is: does our team have the necessary resources and skills to dedicate to the build process? Will that distract us from our key business imperatives?
So many aspects need to be factored in: human power and skill, budget and time constraints, and even physical resources like is there enough hardware for your team to use.
4. Support and maintenance
There’s not only the building, there’s the support. Is that a drain on your resources? Ensuring the package is well documented, tested, and reliable requires an ongoing commitment, so before making the build vs buy decision, it’s important to know your team’s capacity – skillswise and financially – to deliver now and in the years ahead.
The future holds many unknowns – like the need for on-going support and extensions as the project evolves, even if the original coders have left the team.
5. Licensing
On the subject of licenses and agreements, make sure you read the license that comes with any third-party package or component – be that a commercial one, or even one of the many open source variations.
It’s the responsibility of you, as the purchaser, to ensure you’re able to incorporate that package into your specific project and legally use it (or sell it) in the manner your project requires.
6. Size of package
If you’re building a web app and decide to buy a package that has 20 features and only use one, then you’re likely adding unnecessary bloat to your project. Are you sure the package's weight is worth it?
Before deciding on a package, look it up on Bundle Phobia to find out the cost, in file size, to add it to your project.
7. History of updates
If you’re buying a ready-made package or component, it’s worth checking when it was last updated. Looking at a package’s history – such as the commit history or issues list on GitHub – can be a great way to see how committed the contributors are to supporting the package.
If the package was updated a few days ago, and it’s in a mature state, you can be more confident buying it than if a package’s last update was a few years ago.
8. Quality
One final consideration is the quality of the package, particularly when it comes to browser support. While behavior between different browsers is far more consistent than it used to be, don’t forget to ensure your required browser list includes support for the package – especially if they’re using less-than-current (yet still “officially” supported) browsers.
It’s also worth checking if patches are regularly released to handle the frequent browser updates.
There are great reasons to buy an existing package – but also some things to ponder before taking that leap. You’d hate to incorporate a package and have it become obsolete or no longer function with no clear support path.
The verdict: to build, to buy, or buy-and-assemble
Organizations regularly struggle with the decision between build vs buy software. When the need is clear, immediate and has a relatively low potential impact, it makes sense to answer
the question quickly, and get started along the path you’ve chosen.
But for capabilities that are likely to have a far-reaching and long-term impact, it becomes far more complex. It demands significant evaluation and carries serious risks if you don’t take the right level of care and due diligence.
Clearly, companies are under pressure to make the right choice.
But there simply isn’t enough time to build everything they need. So buying is often the only choice. Regardless of what’s chosen though – be that build, buy or buy-and-assemble – the choice is never orderly, neat, or simple.
