Most build-or-buy decisions are made backwards. A team picks a direction first, then goes looking for evidence. The result is either a six-figure custom build that replaced a product costing a few hundred dollars a month, or an off-the-shelf tool that never quite fit and now needs three people to work around it.

After fifteen years and 650+ delivered projects, we have found the decision is usually settled by four questions. None of them are about technology.

The question is not custom or ready-made

It is: where does this process actually live in your business? Software that supports a standard, well-solved function — payroll, email, accounting ledgers, helpdesk ticketing — should almost always be bought. Thousands of companies have already paid to have those problems solved properly. Software that encodes how you win work, price, route jobs or serve customers is a different category. That logic is the business.

Four tests that settle it

1. Is this process a differentiator or a utility?

Write down the process in one sentence. Then ask whether a competitor doing it exactly the same way would hurt you. If the honest answer is no, buy. Your quoting engine, your dispatch logic, your underwriting rules — those are differentiators. Your leave-request form is not.

2. How much of the ready-made product would you actually use?

Take the shortlisted product and map your requirements against it. Three outcomes matter:

• Above 80% fit — buy it, and change your process to match the remaining 20%. This is the cheapest good outcome available to you.
• 50–80% fit — buy it and build around the edges through its API. This is where most mid-sized companies land.
• Below 50% fit — you are about to pay licence fees for software you will fight. Build.

Be ruthless here. Teams routinely score fit at 70% when the real number is 40%, because they count features they will never open.

3. What does the integration surface look like?

Count the systems this software must exchange data with. One or two, and almost anything works. Five or more — ERP, POS, CRM, warehouse, bank, courier, tax portal — and the deciding factor stops being features and becomes whether the product has a real, documented, versioned API. A brilliant product with a closed API is a dead end in an integrated business. This is the single most common reason companies come to us to replace software they bought two years earlier.

4. What is the cost of being wrong?

If the tool fails, what breaks? A marketing automation tool going wrong costs you a quarter of campaigns. A hospital management system going wrong costs you patient safety and a regulator conversation. The higher the cost of failure, the more you should value control over the code, the data and the release schedule — which pushes towards custom or towards a vendor who will contract to your standards.

The cost comparison almost everyone gets wrong

Buy-side costs are visible and custom-side costs are visible. What gets missed is the third column.

• Buy: licence per user per month, implementation, data migration, training, plus annual increases you do not control.
• Build: design and development, then 15–20% of build cost per year in maintenance, hosting and support.
• Workaround cost: the spreadsheets, double entry, manual reconciliation and re-keying that appear when software nearly fits. This is the column no one budgets, and in a 40-person company it routinely costs more per year than either of the other two.

Price the workarounds. A five-year total cost of ownership with that column included flips a surprising number of decisions.

The answer most companies actually land on

Not custom, not off-the-shelf — a spine plus custom edges. Buy the commodity systems. Build the thin layer of software that holds your specific logic, and connect it to everything else through APIs. You end up owning perhaps 20% of your stack: the 20% that is genuinely yours.

This is how most of our ERP and POS work now begins. The client keeps their accounting package, we build the operational layer that their business actually runs on, and the two talk to each other cleanly.

A decision rule you can use today

Buy it if it is a utility, fits above 80%, integrates through a documented API, and failure is survivable. Build it if it encodes how you compete, or if the workaround column is bigger than the build column.

If you are somewhere in the middle, the cheapest next step is not a proposal — it is a two-week discovery that maps your processes against a shortlist and prices all three columns honestly. We run these as fixed-fee engagements precisely because the answer is sometimes do not build anything.

Ezitech has built custom software, ERP and SaaS platforms for 400+ clients across 42 countries. If you are weighing a build-or-buy decision, talk to our team.