Build vs buy advisory
Whether to build it at all
The most expensive software decisions are made before anyone writes code. Building when a product would have done, or buying something that quietly caps your growth — both cost years.
In short
Build versus buy is decided by whether the way you do the thing is a genuine competitive difference or just a habit. Buy when the process is close to standard and the gaps are things you could change about how you work — you are trading control for speed and for somebody else carrying maintenance. Build when no product fits without reshaping the business around the software, or when the difference is why customers choose you. The comparison is total cost of ownership over five years, including the workarounds you will build around a product, not licence fee against build quote.
When it applies
Signals this is the work
If more than one of these is true today, the problem is usually further along than it looks from the outside.
A quote has arrived and nobody can judge it
A vendor has priced a build. No one internal can say whether the scope is right or the estimate real.
"No product does what we need"
Sometimes true. More often it means the evaluation stopped at the first product that did not fit perfectly.
A platform decision locks you in for years
ERP, CRM or commerce. The cost of choosing wrong is measured in years, not licence fees.
You are about to rebuild something that works
The system is unfashionable rather than failing, and a rewrite feels like progress.
The business case is a feature list
Nobody has established what the current process costs, so no option can be judged against it.
How we do it
The sequence
- 01
Price the problem first
Staff time, licences, rework, delay, leakage, risk. Without this number every option looks expensive and none can be compared.
- 02
Define what is genuinely yours
Separate the parts of the process that are a real advantage from the parts that are simply how it has always been done.
- 03
Evaluate products seriously
Against your actual workflow and exceptions, not a feature grid. Including the cost of the workarounds each would require.
- 04
Model five-year ownership
Implementation, licences, integration, maintenance, the upgrade you will be forced into, and the cost of leaving.
- 05
Test the reversibility
What it costs to change your mind in two years. Options that are cheap to exit deserve weight that spreadsheets rarely give them.
- 06
Recommend explicitly
One answer, the rejected options and why, so the question does not reopen every quarter.
What we will not do
The refusals
- Recommend building because we build. That is why the analysis is bought separately.
- Compare a licence fee against a build quote and call it a business case.
- Treat a product demo as evidence about your workflow.
- Ignore the cost of switching away from whatever is chosen.
Questions
Before you ask
Related
Others in Strategize
Tell us what isn't working.
One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.