Product leaders often believe it’s cheaper to buy software than build it. But that’s not always the case. You don’t need a large development team or outside capital to build your own software from scratch.
Whether you decide to build or buy, the technology you adopt must align with your business goals.
In this post, we’re sharing a build vs. buy framework to help you consider the opportunity costs and make an informed decision on whether to buy software off the shelf or build a custom solution.
Table of contents
How to decide when to build versus buy: A decision framework
Gartner forecasts enterprise software spending will total almost $572 billion worldwide by 2022. Companies are investing in enterprise software not just as a platform to run their business on, but the engine that moves it forward.
Whatever option you choose, it must bring real business value. Typically, this value falls into one of three categories:
- Differentiation: The features you’re looking to build or acquire will help you stand out among your competitors. Nobody else is offering it, but your customer research has identified a need among your existing users.
- Market maturity: Conversely, competitors are investing in a new featureset and thus, they’ve become table stakes. You need to build or buy these features to keep up.
- Market share: You may already be a category leader, and growth requires you to expand into new verticals.
Business requirements trump features. Building or buying software that doesn’t align with your business goals or meaningfully help you stand out can be wasteful.
Here are the key factors you’ll need to consider.
The problem your new software or technology will solve
Investing in acquiring or building new software can help you solve a specific problem; one you’re suffering from internally or a pain-point your customers are looking to overcome.
A common barrier to investing in specific solutions often comes from a lack of core competencies. The skills, technology, or experience to build in-house aren’t sufficient.
Acquiring existing software can provide you with a cookie-cutter solution. It can be less costly and faster to implement something that’s “pre-made”.
If nobody else has solved your problem, finding existing solutions may be tricky. This is especially true if you’ve found a better way of solving it than existing products in the market.
The scope of the project
To build a new product or featureset, you must fully understand the scope of the project, resources required, and potential costs before enlisting in-house developers.
Poor project planning can lead to development cycles running over budget or over time. Worse, you may end up with a sub-par product because you simply didn’t have the resources to build what you needed.
To avoid these pitfalls, ensure your project scope includes the following:
- Clearly defined documentation: Building out user stories and acceptance criteria will help your team understand the value your solution must deliver to users.
- Communication and accountability: Avoid misinterpreting requirements by having regular all-hands meetings. Make sure everybody understands the information that is being communicated. Centralize your communication using project and task management tools.
- Stakeholder engagement: Keep senior decision makers and the boardroom informed and involved during the entire project cycle. Seeking their feedback at each milestone will ensure the project keeps on track.
In-house teams need the right project management systems and processes to ensure the build stays on schedule and within budget.
Resources, costs, and time needed to complete
The costs associated with building or buying software go deeper than resources and price tags. Proprietary software will have more cost considerations, but even existing software has customizable and ala carte options that add up fast.
Say you decide to build software in-house. How many people will be contributing? And for how long? New development projects will shift resources from other initiatives.
No-code/low-code solutions can reduce costs and development cycles, and are forecast to grow to 23% by the end of 2021. But no-code software can come with the added cost of technical debt.
Technical debt happens from unexpected bugs and additional development work that results from using short-term solutions (like templates or open-source code). When going the no-code/low-code route, make sure you account for these risks. Bugs can be difficult to identify unless properly QA tested.
Integrations
When building or acquiring new technology, integrations must go deeper than “connecting with Zapier”.
Will your new product need to integrate with your existing product? If there’s an integration issue integrating, who will fix it?
Get clear on the integration plan in your project scope and documentation. If you’re building new technology, define how it will work with your existing software (if it needs to). When buying, evaluate the development languages your acquisition is built on to understand how complex the integration process will be.
Ongoing support once the project is wrapped
Product development and maintenance are important, but you’ll also need customer support when you launch your new product, featureset, or conduct a handover.
58% of American consumers will switch to a competitor due to a bad customer experience. If your customers can’t access the support they need, it won’t matter how impressive your solution is.
Develop training for your customer success teams. Then, launch to a small cohort of users to identify recurring issues or questions. Use these learnings to guide and optimize your customer support processes.
When you can expect to see a positive ROI
Time-to-value also has a direct impact on ROI. Will the software be a part of your business’s core offering? Can you realistically expect the ROI to lead to compound growth?
Shifting requirements is a common hurdle to reducing time-to-value. Development teams must complete the project in a reasonable time frame while making sure the end product solves the predefined problem.
The faster you can deliver a product and drive value (to the business and customers alike), the stronger your upper hand against the competition will be.
Other associated risks
Risks vary based on whether you develop or purchase software. Consider:
- What are the security risks?
- Who is responsible for issues or bugs?
- What happens if the project goes over budget?
- How likely is it that the software development will be delayed?
- What are the risks of working with a particular vendor or platform?
These should all be accounted for in your project scope and development plan.
When to build custom software in-house
Building custom software makes sense if the problem is difficult to solve, complex, or accessible via your product and development team’s capabilities.
The software is tied to your company’s core competencies
Look at your most valuable services or core competencies when deciding what software to build.
If your company specializes in email marketing software, building an email deliverability tool in-house would align with your core company competency.
Custom-built accounting software would not.
Specialized competencies can lead to a “snowflake” scenario. The problem you’re looking to solve is so aligned with your software or service that retrofitting an existing software to meet your needs would be too expensive or impractical.
For example, Penske started offering logistics solutions back in the 1980s. Today, they continue to implement proprietary technology and recently launched a truck rental app.
A truck rental app is a competitive advantage for Penske:
- It simplifies the logistics for customers planning a move
- It drives more awareness for Penske’s locations
- It provides a frictionless way to make reservations
That said, over the years Penske has acquired many software solutions to help them streamline logistics. They’ve custom-tailored each one to their needs by building supporting solutions in-house and integrating them with the acquired technology.
“Supply chain excellence may be part of your core competency, but supply chain software doesn’t have to be.”
When it comes to their rental app, however, building and managing the software in house made the most sense.
In fact, when they launched their Penske Driver app in 2017, it was the “industry’s first fully integrated, custom app that provides truck drivers with easy Hours of Service (HOS) functionality to meet the electronic logging device (ELD) mandate”.
Penske needed to get over a compliance barrier to continue delivering a core competency. That problem was too close to home to outsource and too complex to relinquish one ounce of control.
“The innovative app was custom built by Penske based on extensive customer and driver research and is supported 24/7 by Penske’s in-house staff.”
You need full control
If your operational processes or software need drastic changes, waiting on a third party can negatively impact time-to-value. Owning the development process gives you complete control over the product roadmap, data, and ongoing support.
For example, WordPress development agency Aktura created a custom client portal called Content Snare after feeling frustrated with existing solutions on the market. Their team was spending hours on repetitive administrative and data-entry tasks to collect necessary onboarding documents from clients.
This solution streamlined the onboarding process and led to higher customer retention rates. Full control over the product roadmap allowed them to spin off, rebrand, and sell their software to other agencies and web development shops.
Most out-of-the-box software or low-code platforms may struggle to fully integrate with your existing solutions. Developing your own solution will ensure it has full connectivity.
You have excellent project management and support systems in place
Reliable project management systems are critical for successful development cycles. They’ll help you keep your projects on budget and on time, ensuring you stay the course and solve the problem you set out to.
Take into account potential issues like gold plating and scope creep that could delay the process. Ensure enough resources are dedicated to the teams in charge of bringing your software to life.
You can take advantage of economies of scale
The benefits of your software should compound over time.
For instance, you might build a tool for sales reps that reduces the time it takes to conduct high-impact activities. The more they use your tools, the more deals they’ll close in less time.
This starts by building out a new solution. As the software becomes fully built, you’ll need to create a migration plan to transition all users and data onto the new platform with little interruption.
You have outgrown your existing software
This isn’t uncommon for growing businesses. What once worked may soon reach a ceiling as your product and growth goals become more aggressive.
Uber moved away from Greenhouse and Zendesk to build their own user support platform. While they shared positive case studies with both companies, eventually they needed a more cost-effective solution that aligned with how users interact with their platform.
When to “buy” and adapt existing software
If the problem is well defined, common in your industry, and software can solve 70% of it, then you should consider buying, acquiring, and adapting existing software.
Market expansion: The problem you’re solving is outside core competencies
Many companies build software that doesn’t align with their core competencies and waste their investment as a result.
If you’re trying to solve a common problem that isn’t specific to your company, it’s likely that the right commercial software is out there waiting for you.
This approach works well if you’re looking to capture existing market share. For example, if you’re a category leader in the CRM space and looking to step into marketing automation, then it’d make sense to acquire an email marketing platform to expand your capabilities.
You have strict time, budget, or internal resources constraints
Predicting when it’s time to move on can be easy as software slowly becomes obsolete. However, surprises happen, and a change may be forced on you due to market conditions or explosive growth.
For instance, the pandemic changed the software needs of companies across the world. You don’t always have the luxury of time. Even with the procurement process, you can still deploy existing software faster than a custom build.
Adobe Experience Platform has witnessed competing companies investing up to three years in developing software and features from their product suite. Many of these companies were still not able to meet the needs of the market.
Software requirements and consumer demands shift fast. Your software must keep pace as it’s being built—adapt as the project progresses or risk launching an already outdated product.
You have internal resource constraints
You may not have the time, funds, or staff needed to build software from scratch. After the software is built, you’ll still need to dedicate resources to maintaining and supporting the software.
For many companies, this isn’t feasible. Resources that were dedicated to the initial project need to move on to other initiatives. And if the support workload exceeds the capacity of your existing customer success teams, you’ll struggle to keep up with the influx of tickets.
To overcome this hurdle, you’ll need both the technological resources of the software you’re buying and the people that drive its success.
When to acquire a company outright
There’s a happy medium between using existing software and building a solution from scratch.
Here’s how to decide if acquiring a software or SaaS company is right for you.
You share core competencies
Take your time to research the company you plan to acquire. Do their core competencies align with yours? If not, you’ll run into the same issues when buying and retrofitting existing software.
Say you are a leading email marketing software. Acquiring an up-and-coming competitor, who is growing exponentially, is a smart move.
This competitor has an overlapping audience. Acquiring them as a startup allows your company to capture market share at an attractive price.
You see an existing differentiation
The company’s software could have significant market share or product differentiation that would be difficult to replicate.
If acquiring the company is cheaper than building the capabilities from scratch, it’s worth pursuing. They’ve already invested the time and resources in developing the solution so you don’t have to.
This is especially true if the company has proprietary technology. If there’s a patent for a cutting-edge AI development, replicating their approach in your solution violates their IP. The workaround? Buy them.
You can tap into network effects or economies of scale
In 2017, Target acquired Shipt, a grocery delivery service. In 2020, it was announced they’ll acquire Deliv:
These acquisitions gave them new technologies, a fresh user base, and the transportation logistics that made them a success.
This proved to be a major competitive advantage in 2020 as the majority of the world was in lockdown due to the pandemic.
Owning the software outright and having an in-house team at Target manage it gives them complete control over the product roadmap, data, and support.
You have the potential to acquire key talent and customers
By acquiring a business, you also acquire their employees. It’s a strategic way to hire specific talent or leadership capabilities your company is actively seeking.
For instance, if you want to build out your team’s software developing capabilities, acquiring a company founded by a niche, senior software engineer can help you do that.
Just as acquiring talent, buying a business gives you their entire customer and user base. In this way, company acquisitions foster growth in all areas.
If you are ranked second in a competitive market, acquiring the third or fourth player can help you grow your customer base and create leverage to become a category leader.
Conclusion
Deciding whether to build or buy comes down to competencies, capabilities, and growth goals. If you have the internal chops to build a featureset that will give you a competitive advantage, then it makes sense to do so.
Aggressive growth goals require a different approach. Here, it can be worthwhile to buy technology or an entire company outright. Use this guide as a checklist to make the right strategic decision.
Working on something related to this? Post a comment in the CXL community!
The build vs buy decision is a lot easier than this article:
This is from a great CTO friend of mine with 30+ years of success building tech teams/stacks from start up to enterprise
1) if you make money from it – build
2) if you don’t and there is off the shelf – lease
3) if it doesn’t yet exist (rare for any critical function nowadays) bailing wire as much together as necessary and tell every vendor that has related services to build.