Almost every build-versus-buy conversation starts in the same place: a feature comparison. Someone builds a spreadsheet with products across the top and requirements down the side, and fills in ticks.
It feels rigorous. It is close to useless, for a reason that is easy to state. A feature matrix measures whether a product can be made to do something. It says nothing about what it will cost you to keep it doing that thing, for years, as your business changes around it.
Three questions predict the outcome far better. None of them appear on a feature matrix.
Question one: is this process a differentiator?
Not "is it important". Almost everything a business does is important. The question is narrower: is this one of the things you are genuinely better at than your competitors?
The answer sorts most cases immediately.
If a process is where you win — how you price, how you match supply to demand, how you get a customer from enquiry to delivery faster than anyone else — then encoding it in software that every competitor can also buy is a strange decision. You are converting an advantage into a commodity and paying a subscription for the privilege.
If it is payroll, general ledger, expense claims or holiday booking, the opposite holds with equal force. Building it is an expensive way to arrive somewhere you can already reach, and you will spend the next decade maintaining a worse version of something with a large product team behind it.
The uncomfortable middle is where a differentiating process is hiding inside a standard one. Order management sounds generic. For a company whose advantage is same-day fulfilment, it is not. The useful move is to separate the two: buy the standard part, build the specific part, and be honest about which is which.
Question two: how wide is the integration surface?
Packaged software is excellent at its own domain and poor at the seams between domains. This is not a criticism — it is structural. A vendor optimises for their product's boundaries, and your business does not respect them.
Count the systems that have to agree for this process to work end to end.
This is the question most often answered wrongly, because integration cost is invisible during selection and dominant afterwards. It is worth asking every vendor a specific version of it: not "do you have an API" but "show me the API documentation, and tell me your rate limits and your policy on breaking changes."
Question three: can you fund ownership?
Building is not a project. It is a commitment.
Here is the arithmetic that most business cases omit. A custom system needs, per year:
| Cost | Typical annual share of build cost |
|---|---|
| Hosting and infrastructure | 2–5% |
| Dependency and security updates | 3–6% |
| Support and incident response | 4–8% |
| Small changes and improvements | 5–10% |
| Total | 15–25% |
So a system that cost 100 units to build costs 15 to 25 units a year to own. Over five years, ownership roughly doubles the total. Compare that number with five years of licences, not the build cost alone.
This single question flips more recommendations than the other two combined. A company with a genuinely differentiating, highly integrated process and no budget for ownership should still buy, because an unmaintained custom system becomes a liability in about two years — and then becomes the legacy problem someone is hired to fix.
Putting the three together
| Differentiator? | Integration surface | Ownership funded? | Usual answer |
|---|---|---|---|
| Yes | Wide | Yes | Build |
| Yes | Wide | No | Buy, and revisit when you can fund it |
| Yes | Narrow | Yes | Build only the differentiating part |
| No | Wide | Yes | Buy the parts, build the orchestration layer |
| No | Wide | No | Buy, and budget properly for integration |
| No | Narrow | Either | Buy and configure |
The row worth dwelling on is the fourth. "Buy the parts, build the orchestration layer" is the most common correct answer for established businesses, and it is the one least often chosen — because it is not a decisive-sounding decision. It has no launch moment. It just quietly removes the reason people were reconciling two systems by hand.
What to do with a hybrid answer
If you land on a thin custom layer over existing systems, three rules keep it healthy:
- Do not migrate data you do not have to. Systems of record stay where they are. You are building workflow and interface, not storage.
- Write the integration contract down. Explicitly, including what happens when the vendor changes something. Undocumented integrations are how a vendor's routine release becomes your incident.
- Review it annually. Thin layers drift. Some earn the right to become the system; others should be folded back in. Both are fine — drifting without noticing is not.
The honest summary
If you take one thing: features tell you whether something can work; differentiation, integration and ownership tell you whether it will keep working.
And if you find yourself building a feature matrix, it is worth asking what decision it is actually going to change. In our experience the answer is usually none — the decision has already been made by the three questions above, and the matrix is being built to justify it.
If you want to work through this properly, our build-versus-buy decision tool asks all seven questions we would ask, gives a recommendation, and states the strongest argument against it. Roughly half its outcomes recommend not building.
Written by
Nadeem Sheikh
Software Architect & AI Automation Engineer
Brain Matrix Solutions is deliberately small so that the person on your first call is the person doing the architecture and the person handing it over. There is no sales layer between us, and nothing gets passed to someone junior after you sign.