Build vs. buy: when should a business build custom software?

"Build vs. buy" is a misleading framing because it hides the two options that resolve the majority of operational problems. Before comparing a software licence to an engineering estimate, be clear which of these you are actually choosing between.

• ▸Buy an existing product. A mature product in a well-served category — accounting, payroll, CRM, helpdesk, e-commerce, HR — has absorbed years of edge cases, compliance work, and security investment that you would otherwise fund yourself.
• ▸Configure and integrate what you already own. A large share of "we need custom software" problems are really unconfigured products and missing connections between systems. This is usually the cheapest real fix and often the fastest.
• ▸Redesign the process. If a workflow is illogical, automating it makes the illogic faster and harder to see. Sequencing, ownership, and handoffs are frequently the actual defect.
• ▸Commission custom software. Correct when the workflow is specific to your business, when it is a source of margin or differentiation, or when the systems you must operate between will never be reconciled by a product built for someone else.

Commodity capability is where off-the-shelf products win decisively, and building your own version is usually an expensive way to arrive at a worse outcome.

• ▸The function is standard across your industry and you have no meaningfully different way of doing it.
• ▸The domain carries heavy regulatory or tax complexity that a vendor already maintains — payroll, statutory filing, payment card handling, benefits administration.
• ▸A credible product covers a large majority of the requirement and the remainder is preference rather than operational necessity.
• ▸You need it working in weeks, and the problem is expensive to leave unsolved.
• ▸You have no internal owner for the system after launch, and no budget line for maintaining one.

The honest test: if you can describe the requirement without referring to anything specific about your business, someone has already built it. Buy it.

This is the most commonly missed option. Businesses frequently own capable software they have never configured past its defaults, running alongside two or three other systems that do not exchange data. The felt experience is "our software doesn't do what we need". The actual problem is that nobody connected it.

• ▸Staff re-key the same information into more than one system.
• ▸Reporting requires exporting spreadsheets from several tools and reconciling them by hand.
• ▸A product you already pay for has modules nobody switched on or fields nobody adapted.
• ▸The gap between systems is a data-transfer problem, not a logic problem.

Integration work of this kind sits inside business automation and is typically a fraction of the cost and risk of a new platform. It should be ruled out before a build is considered, not after.

Custom software earns its cost when the way you operate is the thing that makes you competitive, or when the shape of your operation cannot be expressed in anyone else's product.

• ▸The workflow is the differentiator. Your scheduling, pricing, fulfilment, or approval logic is part of why customers choose you, and bending it to fit a product would remove the advantage.
• ▸Nothing fits without distortion. Every candidate product requires you to change how the business runs in ways that cost real money or introduce risk.
• ▸The workarounds have become the system. Spreadsheets, shared inboxes, and manual reconciliation are load-bearing, and the failure cost is already being paid in salary, errors, and delay.
• ▸You need one system across several. The operation spans tools that will never be unified by a vendor, and the connective logic itself is the product.
• ▸The product is the business. You are building something customers use directly — that is digital product engineering, and buying is not on the table.

Work through these in order. A single strong answer in the "buy" column should stop a build.

1. Is the capability commodity or specific?

Commodity means the market has a standard answer. Specific means your version differs for a reason you can articulate commercially, not aesthetically.

2. What is the current cost of not solving it?

Count hours spent on manual handling, error correction, delayed decisions, and lost work. If that number is not clearly larger than the cost of building and maintaining a system, do not build.

3. Who owns the system after launch?

Custom software is an ongoing commitment: dependencies, security patching, and change as the business changes. Birchline publishes Ongoing Engineering from $4,000/month for exactly this reason. If there is no appetite to fund continuity, buy a product where the vendor carries it.

4. How stable is the requirement?

Building around a process that is still being invented produces software that is obsolete on delivery. Stabilise the process first, or scope the build deliberately small.

5. What is the integration surface?

Systems that must be connected, and whether they expose usable APIs, drive more of the cost and timeline than the features themselves.

6. What does failure cost?

High-consequence workflows — money movement, safety, regulated records — justify more engineering rigour and more explicit human control, which raises cost legitimately.

In practice most sound outcomes are mixed: keep the accounting product, keep the CRM, and build the thin operational layer that connects them and holds the logic unique to your business. That layer is often far smaller than the platform a buyer first imagines — which is one reason we scope before quoting rather than after.

A related question worth answering separately: when AI is the wrong tool for a workflow, and how long custom software takes to build.

Birchline Digital is a software engineering practice, and we still tell prospective clients to buy or configure when that is the correct answer. A discovery engagement that concludes "configure what you own and fix two handoffs" has done its job. We would rather lose a build than deliver one a business did not need — that judgement is the thing worth paying for.