Build vs buy software: a decision framework for leaders

Buy when the function is one that every company in your industry performs in much the same way. Build when the way you perform it is part of why customers choose you. Between those two poles, the build vs buy software decision turns on a handful of factors: differentiation, fit, cost over several years, speed, data and compliance, integration and your ability to maintain what you make. The framework below scores each one and adds a third option that is often the right answer, which is to buy and extend.

Start with one question: is this how you compete?

In a 2010 essay on the utility versus strategic dichotomy, Martin Fowler argues that what matters is whether the underlying business function is a differentiator. If the way you do it makes you better than the competition, the software behind it should be as good as you can make it. If not, it is a utility.

His advice for utility functions is blunt: buy the package and adjust your business process to match the software. For strategic functions he makes the opposite case, because running the same software as your competitors limits your ability to stand apart. He also suggests that strategic work is a small minority of what most organizations run.

That gives a useful default. Payroll, accounting, email, ticketing and standard CRM are utilities for nearly everyone. A pricing engine for an insurer, a routing algorithm for a carrier or the core workflow of a software product may be strategic. Be honest here. Teams tend to believe more of their work is special than their customers would.

Three options, not two

• Buy. Subscribe to or license a product, configure it and adapt your process to it.
• Build. Develop custom software that you own and maintain.
• Buy and extend. Take a product or platform for the standard parts and build your own logic on top through its APIs, or assemble several bought components with custom integration between them.

The third option fits when most of a function is standard but one part is yours alone. Commerce is a common example, covered in composable commerce vs monolithic platforms. The risk is heavy customization of a bought product. That can leave you with the costs of both paths: a subscription, plus custom code that breaks when the vendor ships an upgrade.

A build vs buy software scorecard

Score each factor from one, meaning strongly buy, to five, meaning strongly build. Weight the factors by what matters to your business, and have product, engineering, finance and security score separately. The disagreements are more useful than the total. A middle score on most factors usually points to buy and extend.

Count the full cost on both sides

Most comparisons undercount one side. Use the same period for both, long enough to include several years of running costs.

When you build, the first release is only the beginning. Add hosting, security reviews, dependency updates, bug fixes, support, on-call cover and the features users ask for after launch. Add the opportunity cost too: the engineers on this are not working on the product your customers pay for. AI coding tools can reduce the effort of a first version, but they do not remove the cost of owning it.

When you buy, the subscription is only the visible part. Add implementation, integration, data migration, administration, training and growth in seats or usage. Check whether features you will need, such as single sign-on or audit logs, sit in a higher price tier. Add the cost of leaving, including how you get your data out.

Checks to run on a vendor before you buy

Buying moves risk to a vendor. It does not remove it. In 2024, CISA and the FBI published the Secure by Demand Guide, a set of questions for organizations that buy software. It points out that due diligence often looks only at a vendor’s own enterprise security and overlooks the security of the product. Its questions include:

• Does the product support standards-based single sign-on at no additional cost?
• Is multi-factor authentication enabled by default?
• Are security logs available in the baseline version?
• Does the vendor provide a software bill of materials that lists third-party components?
• Has the vendor published a vulnerability disclosure policy?

Beyond security, ask about data export, service levels, the product roadmap, price changes at renewal and what happens to your data if the contract ends. Test the product against your real integration needs in a short trial before you commit. A demo will not show you those gaps.

If you build, build less

1. Build only the differentiating core. Buy the commodity parts around it, such as sign-in, payments, messaging and search.
2. Start with a small first release and learn from use. The guide to how long it takes to build an MVP covers what that involves.
3. Design clean APIs between what you build and what you buy, so either side can be replaced. This is API and systems integration work.
4. Name who will maintain the software after launch before you start.
5. Set review triggers. Revisit the decision when a vendor changes its pricing, a product catches up with what you built, or your volume changes sharply.

How YLinkTech helps

We help teams make this decision with evidence and then carry it out, whichever way it goes. Where building is right, our custom software, web and mobile development team delivers working software in your repositories and cloud accounts. Where buying is right, we integrate the product with the systems around it. Both are part of our digital product engineering practice. Tell us what you are weighing and we will give you a straight view.

Frequently asked questions

Sources

• Martin Fowler: Utility Vs Strategic Dichotomy
• CISA: Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem

This article is general information, not professional advice. See our Disclaimer.