Build vs buy for business software: a decision checklist for mid-sized companies

“Should we buy a product or build our own?” is the wrong first question. The better one is: which parts of this process are generic, and which are the reason customers choose us? Standard software is excellent at the generic parts and mediocre at the rest. Custom software is the reverse. Most mid-sized companies need both — and the expensive mistakes come from putting the wrong part on the wrong side.

This guide gives you a way to decide that survives a steering-committee meeting, and a checklist you can score.

When standard software wins

Buy when the process is commodity, well understood and not a differentiator: accounting, payroll, HR administration, e-mail, office documents, CRM basics, e-commerce storefronts, ticketing. Someone has already made every mistake you are about to make; their product encodes the fixes. Typical signals:

• Ten credible products exist and they look alike.
• Your requirements fit the product’s default workflow with minor configuration.
• Your competitive advantage lies elsewhere.
• The vendor’s roadmap is moving in your direction.
• Per-user pricing stays reasonable at your headcount.

In these cases, buy — and resist the urge to customise the product deeply. Heavy customisation of standard software combines the disadvantages of both worlds: you pay licences and you own code that breaks on every upgrade.

When custom software pays off

Build when the process is specific to how you make money, when the data lives in several systems that no product connects the way you need, or when a product exists but its licence cost grows faster than your use of it. Typical signals:

• The process is a reason customers choose you (a partner workflow, a pricing model, a service promise).
• Every product demo ends with “we can work around that”.
• The valuable part is the logic between your systems: ERP, CRM, documents, identity.
• You need partner- or customer-specific behaviour (permissions, rules, documents) that products handle only with consultants.
• A product’s per-user or per-transaction price would exceed a build’s total cost within two or three years.
• Regulatory or data-residency constraints rule out the available products.

Build is also the right answer for replacing spreadsheets and e-mail rituals that run operations — not because spreadsheets are bad, but because the process has outgrown them and no product models it.

The hybrid most companies actually need

The pattern that works in practice: buy the systems of record, build the layer that makes them yours.

• Keep the ERP, CRM, accounting and payroll products.
• Build the customer or partner portal that reads from and writes to them.
• Build the integration layer that keeps them consistent.
• Build the internal tool for the one process that is specific to you.
• Modernise the custom application you already depend on, instead of forcing it into a product that does not fit.

This keeps the commodity parts cheap and the differentiating parts in your hands. It also keeps the custom surface small — which is what keeps it maintainable.

A scoring checklist

Score each statement 0 (disagree) to 3 (strongly agree). Sum the two columns.

Points towards buy	Points towards build
The process is standard in our industry	The process is a reason customers choose us
A product fits ≥ 80 % of requirements without custom code	Products fit < 60 % or need heavy customisation
Licence cost at our size is modest and predictable	Licence cost grows with users/transactions faster than we do
The vendor is stable and its roadmap matches ours	We need behaviour the vendor will not prioritise
We have no need to integrate deeply with other systems	The value is in connecting several systems of record
Time-to-live matters more than fit	Fit matters more than being live next month
We lack anyone to own custom software long-term	We have (or will retain) technical ownership

A clear margin either way is a decision. A close score usually means: buy the core, build the layer — and consider a short discovery sprint to map which is which.

Questions to ask before committing either way

• Who owns it in three years? A product has a vendor; custom software needs an owner — internal or a retained partner — and a maintenance budget (plan 10–20 % of build cost per year).
• What is the exit? Can we export our data from the product? Can another team take over the custom code? (If a vendor cannot answer the second question, that is your answer.)
• What is the total cost over five years — licences, implementation partners, customisation, upgrades — versus build, hosting and evolution?
• Which decision is reversible? Starting with a product and replacing it later is often cheaper than the reverse; building a thin custom layer over a product is cheaper than either.

A note on our own bias

We build custom software, so read our advice accordingly. It is also why our written assessment includes a build-vs-buy recommendation and why we tell people to buy when that is the right answer: a client who should have bought a product is an unhappy client twelve months later, and we would rather not meet them that way.

Unsure which side your project falls on? Describe it in a project enquiry and we will give you our written view, including “buy”, within two business days.