The question comes up at every stage of an organisation's growth: do we build it, buy something that already exists, or configure a platform to do roughly what we need? The wrong answer costs time, budget, and operational stability. The right answer depends on specifics that are rarely examined carefully enough before the decision is made.
This is not a framework for the sake of having a framework. It is a set of questions and signals that, taken seriously, produce better decisions than the ones most organisations make — which typically default to whichever option the person leading the project is most comfortable with.
Why the default options are usually wrong
Most organisations approach the build/buy/configure decision with a bias already in place. IT teams often prefer to buy or configure — they manage risk by choosing something that exists. Operations teams often want to build — because they have suffered too long with software that does not fit how they actually work. Senior leadership often wants to configure a platform they have seen work elsewhere, regardless of whether the context is comparable.
None of these instincts is necessarily wrong. But they are not analysis. The decision needs to be made by examining the actual requirements against the actual market — not by applying a preference.
The three questions that structure the decision
Before you reach a conclusion, you need clear answers to three questions:
1. How differentiated is your process?
If your process is genuinely different from how other organisations in your sector operate — different enough that your operational advantage or regulatory compliance depends on it — that is a signal pointing toward build. If your process is substantially similar to others in your sector, even if it feels unique internally, that points toward buy or configure.
The test is whether an existing product, used as designed, would require your team to change more than 20% of how they currently work. If the answer is yes, and those changes would compromise quality or compliance, build is worth evaluating. If the answer is yes but the changes are workflow preferences rather than substantive requirements, buy and adapt the workflow.
2. What is the total cost of the wrong choice?
The cost of building the wrong thing is high: development time, maintenance overhead, a product that diverges from what the team needs as requirements evolve, and no vendor to call when something breaks. The cost of buying the wrong thing is also high: licence costs for software nobody uses effectively, workarounds that consume staff time, and eventually a migration project that costs more than building would have. The cost of configuring the wrong platform is somewhere between the two, but often underestimated.
The question is not which option is cheapest. It is which option is cheapest given the realistic cost of failure — which requires an honest view of what failure would actually look like in your context.
3. What is your capacity to execute?
Build requires either an internal development team or a trusted external supplier, a clear specification, and the discipline to manage a software project. Configure requires someone who can administer the platform as it evolves — this is often underestimated. Buy requires a rigorous evaluation process and the organisational willingness to change workflows to fit the tool.
Many organisations choose to build because they have a development team, even when the market has a perfectly adequate off-the-shelf product. Many organisations choose to configure a platform because it looks cheaper on paper, even when the administrative overhead will consume a full-time role. Capacity questions matter.
Signals for each option
| Option | When it is right | Common mistake |
|---|---|---|
| Buy (off-the-shelf) | Your process matches how the market has designed the product. The vendor's roadmap aligns with where your requirements are heading. Switching costs are manageable. You do not need to own the IP. | Buying a product built for a different customer profile and spending years adapting to it rather than admitting the fit was wrong at the outset. |
| Configure (platform) | Your process is distinct but can be expressed in the building blocks the platform provides. You have the internal capacity to administer it. Your requirements will evolve and you need flexibility without rebuilding from scratch. | Underestimating how quickly you reach the ceiling of what the platform can do, and discovering the migration cost only when you are deeply embedded. |
| Build (custom) | Your process is the product — the software is your competitive or regulatory differentiator. No existing product comes within reach of your requirements. You have a trustworthy supplier and enough specification clarity to avoid a runaway project. | Choosing to build because existing products were never properly evaluated, or because the team overestimates how unique the requirement actually is. |
The configure option is undervalued and over-stretched
Configuration platforms — tools like no-code workflow builders, case management platforms, and sector-specific SaaS products with open configuration layers — occupy a genuinely useful middle ground that many organisations overlook. They are faster to deploy than custom build, more adaptable than rigid off-the-shelf products, and often cheaper in the short term than either alternative.
The problem is that the ceiling is real and arrives sooner than expected. A configuration platform can do exactly what you need until the moment your requirements exceed what its building blocks can express. At that point, you have three choices: accept the constraint, pay for custom development on top of the platform (which combines the cost of both approaches), or migrate to something else with all the disruption that entails.
The right question is not "can we configure a platform to do this?" — the answer is almost always yes, for some value of yes. The right question is: "will this platform still be sufficient in three years, when our requirements have evolved in the ways we can reasonably predict?"
For regulated industries. If you operate in a regulated environment — property management under the Building Safety Act, road freight under DVSA requirements, financial services under FCA rules — the configuration ceiling question is especially important. Regulatory requirements evolve, and a platform that cannot be adapted to accommodate new obligations becomes a compliance liability. Know the platform's limits before you embed.
What makes a specification good enough to build against
If you decide to build — either custom software or custom configuration — the quality of the specification determines the outcome more than any other single factor. Most failed software projects fail because the thing being built was not clearly enough defined before development began.
A specification is sufficient for build when it can answer:
- Who uses the system and what they are trying to accomplish, described at the level of their actual work rather than the software feature
- What data enters the system, what form it takes, and what needs to come out
- What rules govern the process — the conditions, exceptions, and edge cases
- What integrations are required with other systems, and what those systems can currently do
- What compliance obligations the software must support, with specific reference to the regulation rather than a general statement about GDPR or data security
- What failure looks like — what happens when the system produces the wrong output, and how it is corrected
If you cannot answer these questions before the project starts, the specification is not ready. Beginning development before the specification is ready is how you end up paying twice.
The evaluation process for buying
Buying off-the-shelf software should involve more than a product demo. The demo shows what the product can do in controlled conditions. It does not show what it does with your data, in your workflow, against your regulatory requirements.
A serious evaluation includes a structured trial using your own data and processes, conversations with reference customers who are comparable to your organisation (not the vendor's selected success stories), a review of the vendor's release history and support response times, and an honest assessment of the contract terms — particularly around data portability, which matters enormously if you ever need to leave.
Three products minimum. Evaluated by the people who will use them daily, not just the people approving the budget. Documented criteria set before the evaluation begins, not shaped by whichever product made the best impression.
When you have already made the wrong choice
Most organisations reading this are not making the decision for the first time. They are living with a previous decision that was wrong, and trying to work out whether to stay, adapt, or migrate.
The signals that a previous choice has failed:
- Your team has built significant manual workarounds around the software — spreadsheets that duplicate data, email chains that should be in the system, processes that happen outside the tool
- The software does not reflect how the work actually happens, and staff navigate the gap between the tool's model and reality every day
- Your compliance position depends on manual checks because the software cannot enforce the rules automatically
- Vendor support has become slower, or the product roadmap has moved away from your use case
- You are paying for a significant volume of unused functionality
The temptation is to stay because migration is painful. Migration is painful. But the cost of migration is a one-time cost. The cost of the wrong software is paid every day, in staff time, in error rates, in compliance risk, and in the friction that compounds across every person who touches the system.
The honest question. If you were making the decision today, with what you know now, would you make the same choice? If the answer is no, the remaining question is not whether to change but when — and the answer to when is almost always sooner than feels comfortable.
Where purpose-built software fits
There is a category of software that sits between off-the-shelf and fully custom: purpose-built products designed for a specific sector or operational context, built by people who understand that context deeply. This is what we build at Tiri.Tese — software for property operators, compliance teams, and road freight carriers who have exhausted the generic options.
Purpose-built software is not the same as bespoke. It is not built from scratch for one organisation. It is built from a deep understanding of a sector's specific requirements, with enough flexibility to accommodate the variation between organisations that operate in the same space. It is closer to buy than to build, but without the compromises that come from a product designed for the broadest possible market.
The distinction matters because purpose-built software can be evaluated like any other product — trialled, referenced, compared — but it addresses requirements that generic products cannot. For organisations where the generic options have failed or never quite fit, it is worth knowing that this category exists.
The decision framework still applies. But the option set is larger than build, buy, or configure a general-purpose platform.