Sooner or later every growing business hits the same fork in the road: a process has outgrown spreadsheets and email, and someone has to decide whether to buy an existing product or commission something built for the purpose. The build vs buy software decision is rarely about which option is cheaper on day one. It is about which option fits the way your business makes money, and which one you can still live with in five years.
This article sets out a framework you can apply to almost any system, from a customer portal to an inventory tool.
Start with the question behind the question
Before comparing products or quotes, write down in one paragraph what problem you are solving and how you will know it is solved. "We need a CRM" is a solution. "Sales leads are lost because nobody knows who followed up last" is a problem. Framing it as a problem stops the discussion from drifting into feature wish lists, and it often reveals that a simpler change (a shared inbox rule, a cheaper subscription) would do.
The core test: is this a differentiator or a commodity?
The most useful single question in any build vs buy software decision is whether the process gives you a competitive edge.
- Commodity processes work much the same in every company: payroll, accounting, email, basic HR, ticketing. Thousands of businesses have the same needs, and mature products already encode good practice. Building your own here usually means paying to reinvent something worse.
- Differentiating processes are the ones customers notice and competitors cannot easily copy: a unique pricing engine, a specialised booking flow, a logistics model nobody else runs. Forcing these into a generic product can flatten exactly what makes you different.
A reasonable default is to buy for commodities and consider building for differentiators. Most of the hard cases sit in between.
Six factors to score in a build vs buy software decision
For the in-between cases, score each option against the factors below. A simple 1 to 5 scale is enough; the point is to make trade-offs visible, not to produce a precise number.
1. Fit to requirements
List your must-have requirements and check how many an existing product meets out of the box, how many need configuration, and how many are simply impossible. If a product covers most needs and the gaps are minor, buying is attractive. If the gaps are in your core workflow, workarounds will cost you every day.
2. Total cost of ownership
Total cost of ownership (TCO) means every cost across the system's life, not just the purchase price. For bought software that includes subscriptions per user, add-ons, implementation, data migration, training and price rises at renewal. For custom software it includes design, development, testing, hosting, security updates and ongoing changes. Compare both over the same period, typically three to five years.
3. Time to value
A configured product can often be in use within weeks. A custom build takes months before anyone benefits. If the opportunity is time-sensitive, that gap matters more than long-run cost.
4. Control and flexibility
With bought software, the vendor decides the roadmap, the pricing and sometimes the data format. With custom software, you own those decisions, along with the responsibility for them. Ask how much it would hurt if the vendor dropped a feature you rely on, raised prices sharply or was acquired.
5. Integration
Few systems live alone. Check whether a product offers a documented API (an interface other software can call) and connectors for the tools you already use. Poor integration is one of the most common hidden costs of buying.
6. Capability to maintain
Custom software is never finished. Someone must fix bugs, apply security patches and adapt it as the business changes. If you have no in-house team and no long-term development partner, a build can quietly decay.
A worked comparison
| Factor | Favours buying when… | Favours building when… |
|---|---|---|
| Fit | Your process is standard | Your process is unusual and core to revenue |
| Cost | User counts are modest and stable | Per-user fees would grow steeply with scale |
| Speed | You need results this quarter | You can invest now for long-term advantage |
| Control | Vendor dependence is acceptable | Data, pricing or roadmap control is strategic |
| Integration | Ready-made connectors exist | You must tie together several bespoke systems |
| Maintenance | You lack technical staff | You have a team or committed partner |
Do not forget the middle options
Build vs buy is rarely binary. Several hybrid routes are worth considering:
- Buy and configure: many platforms allow custom fields, workflows and reports without code.
- Buy and extend: use a product's API or plugin system to add the few features it lacks.
- Adopt open source: a mature open source application gives you a working base with no licence fee and full access to the code, which you can adapt. Our open source solutions page explains how that route works in practice.
- Build around a core: buy the commodity backbone (accounting, payments) and build only the customer-facing layer that differentiates you.
Warning signs on each side
You may be leaning towards building for the wrong reasons if the main argument is "we could do it better", nobody has costed maintenance, or the requirements are still vague. You may be leaning towards buying for the wrong reasons if the demo looked impressive but nobody tested your actual workflow, or if the plan depends on the vendor building a missing feature "soon".
Making the decision stick
Write up the decision with the scores, the assumptions behind them and the main risks. Revisit it at a set point, such as the first contract renewal. Circumstances change: a bought product that fitted at twenty users may not fit at two hundred, and a custom build may become a commodity once the market catches up.
If the choice is genuinely close, an independent assessment from someone with no product to sell can help. That is the role of software consulting: weighing the options against your requirements rather than a vendor's catalogue.
Key takeaways
- Define the business problem before comparing solutions.
- Buy for commodity processes; consider building for those that differentiate you.
- Compare total cost of ownership over three to five years, not the first invoice.
- Look at hybrid options: configure, extend, open source, or build only the layer that matters.
- Record the reasoning and revisit it when your scale or market changes.