Guide
Decide Build or Buy on Ownership and Fit, and Let Cost Come Last
A cost spreadsheet hides the decisions that matter. We help you settle fit, pace of change and ownership first, then build the part that is yours and buy the rest.
4-minute read5 November 2026
In Brief
- A build-or-buy spreadsheet rests on assumptions about modification and lifespan. Heavy modification can remove most of the benefit of buying, and a build with no owner in year five becomes a system no one understands.
- We see four actions: ask whose rules the software encodes, ask who sets its pace of change, name the team that owns it in year five, and estimate modification honestly. Cost comes last.
- Thinqmesh builds only what a product cannot do for you, keeps the first version small, and hands over the code and documentation in your own repository.
A build-or-buy decision usually opens with a spreadsheet: licence fees in one column, engineering salaries in the other. The comparison looks rigorous and is mostly assumption. The buy column depends on how much the product will be modified, and the build column depends on how long the system will live and who will look after it. Those are the real decisions.
Cost Belongs at the End of the Comparison
Technology companies employ capable engineers, so building always looks feasible, and the engineers are often the ones evaluating the alternatives. Purchasing leans towards whatever can be contracted cleanly. Each instinct is understandable, and each needs a method.
We recommend answering four questions in writing first: whose rules the software encodes, who sets its pace of change, how much modification buying would involve, and which team owns it in year five. Once those are settled, the arithmetic is simple, and it often stops being close. Build where the work makes your business different. Buy the rest.
Four Questions to Answer Before You Compare Cost
Answer them in writing, and the arithmetic often stops being close.
Whose Rules Does the Software Encode?
Software that applies your own limits and processes may carry knowledge that a vendor does not have.
Payroll, ticketing and the general ledger follow rules that competitors share, so buying suits them. A system that applies your own test limits or manages staged release of firmware on your products belongs to your business. Ask whether a capable competitor would run the process differently for a good reason.
Get started
- List the processes you are considering building.
- Mark those where your rules differ from the market's.
Who Sets the Pace of Change?
Some software changes when you decide, and some when a standard or a regulator decides.
A vendor can absorb the second kind for all its customers. If your requirements shift with every product generation, a vendor roadmap will rarely keep pace. Ask for the last three years of real changes to the process and note who caused each one.
Get started
- List the changes made to the process in the last three years.
- Mark each as driven by your business or by an outside rule.
Who Owns It in Year Five?
Internal tools compete for the same engineers as the product.
When a launch slips, the people who wrote a tool are reassigned, and the system keeps running while its knowledge fades. Name the team, by function and budget line, that will own it after the first release, and ask an executive to sign that commitment.
Get started
- Write down the name of the team that will own it after launch.
- Have a senior sponsor confirm their time in writing.
How Much Modification Would Buying Involve?
Buying and then heavily modifying deserves more suspicion than either pure option.
Even small modifications to a product can remove most of its benefits, because each upgrade has to carry them forward. Estimate the modification honestly before any licence figure is requested, and compare the result with the build.
Get started
- List every change you would need on top of the product.
- Ask the vendor how each change is carried through upgrades.
How Thinqmesh Solves This
We build only what a product cannot do for you. We map the process with the people who perform it, then agree in writing what the first version must do, and the rest is bought.
- Week 1
The Process, Mapped With Its People
We map the process with the people who perform it, and agree in writing what the first version must do.
- Week 2
Short Cycles, Working Software
Software is delivered in short cycles, so that progress is visible and direction can change early.
- Week 3
Tested on Your Real Scenarios
Testing uses your own scenarios and data, and the code sits in your repository from the start.
- Week 4
A First Version in Use
A first working version of defined scope is in your hands, with documentation your team can continue from.
You finish with a first working version, the code in your own repository and documentation your team can continue from. Moving to your own team or another supplier is a straightforward handover.
