Written by Technical Team | Last updated 20.08.2026 | 20 minute read
Choosing new business software is often presented as a simple build-versus-buy decision. Either you purchase an existing product, or you develop something yourself.
For straightforward requirements, that distinction can be useful. For complex organisations, it is usually inadequate.
The real decision is more nuanced. You may be able to buy and configure an established software product. You may decide that the capability is strategically important enough to build and maintain internally. Or you may need bespoke software designed around your organisation, but choose to develop it with a specialist technology partner rather than creating a permanent internal software engineering function.
Those three routes — buy, build or bespoke — have very different implications for cost, risk, speed, control, flexibility and long-term ownership.
The difficult part is that there is rarely an objectively correct answer in isolation. A commercial SaaS platform may be dramatically cheaper than bespoke development for one organisation and an expensive constraint for another. Building internally can create valuable organisational capability, but it can also leave a business maintaining software it never intended to become a software company to support. Bespoke development can provide an excellent fit around complex operations, but it is difficult to justify when the underlying requirement is fundamentally generic.
The wrong decision is rarely caused by choosing one route over another. It is caused by evaluating the options against the wrong criteria.
Purchase price is one of those criteria, but only one. Implementation effort matters. So do integration complexity, data ownership, security, internal capability, regulatory requirements, process differentiation, scalability, user experience, supplier dependency and the cost of changing direction several years later.
For organisations replacing legacy software, consolidating disconnected systems, automating complex processes or creating business-critical digital platforms, the decision deserves to be treated as a strategic technology investment rather than a procurement exercise.
This framework is designed to help make that decision.
The traditional build-versus-buy question assumes that software is a relatively self-contained product.
You identify what the organisation requires, find products that provide those features, compare their cost with the estimated cost of development and choose whichever route appears to offer the best value.
That model works reasonably well for genuinely standardised requirements.
Very few organisations would seriously consider developing their own email platform, video conferencing system or basic office productivity suite. Mature products already solve those problems extremely well. The competitive benefit of developing an alternative would rarely justify the investment required to create, secure and maintain it.
The situation becomes much less straightforward when software sits inside the organisation’s operating model.
Consider a platform responsible for managing customers, cases, orders, assets, appointments, workflows, approvals, documents and reporting across several departments.
On paper, this may resemble a CRM, ERP, workflow management or case management requirement. Commercial products exist in every one of those categories.
The question is whether buying one actually solves the underlying problem.
A product may provide 80% of the required functionality but require employees to significantly change how they work. Another may support the workflows but struggle to integrate with existing systems. A third may offer extensive configuration but become increasingly difficult to upgrade once heavily customised.
The apparent 20% gap between the product and the requirement can therefore become disproportionately expensive.
Organisations frequently underestimate this problem because software procurement tends to focus on features rather than operational fit.
A requirement list might state that the system needs customer management, reporting, permissions, approvals and document storage. Several vendors can tick every box.
The more revealing questions are different.
How does information move between departments? Which exceptions occur in the process? Which decisions require human judgement? Where does data originate? Who is allowed to change it? Which systems need to remain authoritative? What happens when an external service is unavailable? What audit history must be maintained? Which processes are genuinely distinctive to the organisation?
Two businesses can therefore purchase the same category of software while having completely different suitability requirements.
This is why complex software decisions should begin with business capabilities and constraints rather than products.
There is another important distinction. Building software does not necessarily mean building it internally.
An organisation may determine that commercially available products cannot adequately solve the problem but have no strategic reason to employ product managers, UX designers, software architects, developers, testers and DevOps engineers permanently.
Commissioning bespoke software from a development partner therefore represents a third route.
The organisation owns the problem, strategic direction and usually the resulting software and data, while specialist capability is provided externally.
That distinction matters because the business case for internal development is not the same as the business case for bespoke software.
The question is not simply: should this software exist uniquely for us?
It is also: who should be responsible for creating and evolving it?
Buying commercial software is usually strongest when the problem being solved is common and the organisation can accept the operating model built into the product.
This is an important point.
Buying software does not simply mean purchasing functionality. You are also purchasing somebody else’s assumptions about how that functionality should work.
A CRM platform contains assumptions about customers, opportunities and sales processes. An ERP system contains assumptions about finance, procurement, inventory and operations. A service management platform contains assumptions about incidents, requests and workflows.
Those assumptions can be beneficial.
A mature software product may embody years of industry learning. Adopting it can encourage an organisation to simplify inconsistent processes rather than encoding years of historical complexity into another system.
Buying can also dramatically reduce time to value. Authentication, administration, security controls, mobile access, reporting and infrastructure may already exist. Updates, patches and new features are usually handled by the supplier.
This is particularly attractive for capabilities that are necessary but not strategically differentiating.
The danger begins when organisations buy a product and then attempt to make it behave like bespoke software.
Configuration itself is not a problem. Most enterprise software is designed to be configured.
But there is a point at which configuration becomes structural compromise.
The organisation creates increasingly complicated workflows, custom fields, plugins, scripts, integrations and workarounds to bridge the difference between how the product operates and how the organisation needs to operate.
The business technically owns a commercial product, but begins carrying many of the costs normally associated with bespoke software while retaining considerably less control.
Building internally sits at the opposite end of the spectrum.
Internal development offers maximum control over priorities, architecture, data and product direction. The development team can work continuously with employees and users, build deep domain knowledge and respond directly to changing requirements.
This can be extremely valuable when software is central to the organisation’s competitive advantage.
For a digitally native business, software may effectively be the product. In other organisations, proprietary technology might underpin a unique operating model that competitors cannot easily reproduce.
Internal capability can then become a strategic asset rather than simply an IT function.
However, creating software is only the beginning.
A serious internal software capability requires far more than several developers.
Someone needs to own product decisions. Architecture needs to be maintained. Security vulnerabilities need to be addressed. Dependencies need updating. Infrastructure must be operated. Users require support. Data needs governing. Testing must continue. New employees need onboarding into the codebase. Documentation needs maintaining. Technical debt needs controlling.
The organisation is effectively choosing to become responsible for a software product indefinitely.
That responsibility is frequently underestimated during the initial investment decision.
The third option is bespoke software delivered with a specialist partner.
This model is appropriate where the organisation needs software shaped around specific workflows, integrations, users or strategic requirements but does not want to develop every capability internally.
A good bespoke development partner should provide much more than additional programming capacity.
The value should come from discovery, product thinking, technical architecture, user experience, engineering, testing, security, delivery and long-term support.
This model can combine much of the control of internal development with access to an established multidisciplinary software team.
It also creates its own dependencies, which need to be managed properly. Intellectual property arrangements should be clear. Source code access should be straightforward. Infrastructure and deployment should not be unnecessarily opaque. Documentation should make future handover possible. The organisation should understand its architecture rather than becoming entirely dependent on knowledge held by a supplier.
The objective should not be to eliminate dependency entirely. Almost every modern technology environment depends on cloud providers, libraries, platforms and suppliers.
The objective is to make those dependencies deliberate, visible and manageable.
There is also a fourth outcome hidden within these three options: a combination.
Many of the best enterprise systems are neither completely bought nor completely bespoke.
An organisation might purchase a mature identity platform, accounting system and communications service while developing its unique operational workflow around them. A commercial CRM might remain the authoritative customer database while bespoke software handles specialist fulfilment. A legacy system might be retained temporarily while APIs and new interfaces progressively replace individual capabilities.
Modern software architecture makes this composition increasingly practical.
The important principle is simple: do not build commodity capability unnecessarily, but do not force strategic or highly specialised processes into commodity software purely because the product exists.
A useful decision should examine several dimensions together rather than attempting to find a single deciding factor.
The following seven tests provide a practical framework.
Start by asking what the software actually enables.
If it supports a generic administrative function, commercial software should normally receive a strong presumption in its favour.
If the system determines how the organisation delivers its service, differentiates itself, creates intellectual property or competes, the argument for greater ownership becomes stronger.
This does not mean every strategically important system needs to be bespoke.
It means strategic importance changes the cost of compromise.
Imagine two organisations both evaluating scheduling software.
For the first, scheduling simply allows employees to book internal meetings. There is little reason to build anything.
For the second, scheduling determines how thousands of field engineers are allocated across regions according to skills, customer priority, travel time, contractual obligations and equipment availability.
Both requirements can technically be described as scheduling.
They are not remotely equivalent technology decisions.
Organisations often believe they are more unique than they are.
Years of local process decisions, organisational history and legacy systems can make normal activities appear highly specialised.
Before commissioning bespoke software, challenge every supposedly unique requirement.
Why does the process work this way?
Is the variation commercially important, legally required or valuable to users?
Or is it simply how the organisation has always operated?
This question can prevent expensive software from preserving inefficient processes.
However, the opposite mistake is equally common.
Complexity does not disappear because a software vendor describes something as best practice.
If the process is genuinely valuable, forcing it into a rigid commercial product can transfer software complexity into operational complexity.
Employees start working outside the system. Spreadsheets reappear. Data is copied manually. Teams invent unofficial processes. Reporting becomes unreliable because the software no longer represents how work actually happens.
The organisation has technically standardised its software while fragmenting its operations.
Integration is one of the biggest reasons apparently straightforward purchases become complex technology programmes.
A modern organisation rarely operates a single system.
Customer data may exist in a CRM. Finance information sits in an ERP platform. Documents are held elsewhere. Authentication comes from an identity provider. Operational records may remain in a legacy database. External partners provide APIs. Business intelligence platforms consume information downstream.
A new system needs to exist within that environment.
The important question is therefore not merely whether a product has an API.
It is whether the whole architecture can support the required movement of data reliably, securely and maintainably.
Consider data ownership.
If a customer’s address changes, which system becomes authoritative? Does the new application update the CRM, or does the CRM publish the change? What happens if one system is unavailable? How are duplicates identified? What happens when data structures differ?
These are architecture decisions, not connector decisions.
A purchased product that integrates cleanly can be an excellent choice.
A purchased product surrounded by dozens of fragile synchronisation processes can become an architectural liability.
Control has several dimensions.
There is control over functionality, but also data, deployment, security, interfaces, performance, roadmap and commercial terms.
When buying software, the supplier decides how the core product evolves. Features can change. APIs can be deprecated. Pricing models can be altered. Product lines can be merged or discontinued.
That is not inherently problematic. In exchange, the customer receives ongoing investment without funding the entire development programme.
But dependency should be considered before the system becomes critical.
Ask what would happen if the organisation needed to leave the platform in five years.
Could the data be exported in a usable form? What about documents and audit histories? Are integrations based on documented interfaces? Are there proprietary data models that would be difficult to reproduce? How much business logic exists inside vendor-specific configuration?
The cost of entering a platform is visible.
The cost of leaving one often is not.
Bespoke software introduces different control considerations. Owning the source code is valuable, but source code alone does not guarantee independence.
If nobody understands how the software is deployed, if documentation is poor or if the architecture relies unnecessarily on obscure proprietary services, theoretical ownership may provide little practical mobility.
Exitability should therefore be designed into every option.
The idea that buying automatically transfers security risk to a vendor is incorrect.
Commercial SaaS can provide extremely mature security capabilities that would be expensive to recreate internally. Dedicated security teams, independent audits, sophisticated monitoring and rapid patching can make established platforms considerably safer than poorly maintained bespoke software.
But the organisation remains responsible for choosing the service appropriately and configuring and using it correctly.
Where sensitive or regulated information is involved, the evaluation should go beyond a checklist of certifications.
Understand where data is processed, who can access it, how identities are controlled, what is logged, how backups operate, what suppliers sit further down the technology supply chain and how incidents will be handled.
Bespoke development gives organisations greater architectural control, but simultaneously increases responsibility.
Security needs to be built into design, development, infrastructure and ongoing maintenance.
The right question is not whether bought or bespoke software is inherently more secure.
It is which route allows the organisation to manage its particular risks most effectively.
Commercial products frequently win on initial speed.
An established SaaS platform might be provisioned almost immediately.
But “available” is not the same as “implemented”.
Enterprise implementation can include procurement, configuration, migration, integrations, identity management, training, process redesign, testing and change management.
The apparent time advantage can narrow significantly where requirements are complex.
Bespoke development takes longer to create initial capability but provides another option: progressive delivery.
The business does not necessarily need to wait for a complete replacement platform.
A well-designed programme might begin with the highest-value workflow, integrate with existing systems, migrate a particular user group and gradually expand.
This is especially useful in legacy modernisation where a big-bang replacement creates unacceptable operational risk.
Time to value should therefore be measured as the time until the organisation receives a meaningful business outcome, not the date a licence is activated or development begins.
This final test applies whichever route you choose.
Software cannot be completely outsourced as an organisational responsibility.
A company buying SaaS still needs people who understand its processes, architecture, data, security requirements and supplier relationship.
A company commissioning bespoke development still needs empowered stakeholders who can prioritise requirements, make decisions and define what success means.
And an organisation building internally needs considerably deeper product and engineering capability.
One of the most dangerous situations occurs when an organisation assumes choosing an external supplier removes the need for internal ownership.
The opposite is true.
The more strategically important the software, the stronger internal ownership needs to be.
A simple initial assessment can therefore ask:
No scorecard should make the final decision automatically. Its purpose is to expose where the strongest arguments sit and, more importantly, where assumptions need investigating.
Cost comparisons are where build-versus-buy decisions are most frequently distorted.
Commercial software appears easy to price because there is normally a licence or subscription figure.
Bespoke development appears expensive because much of the investment is visible near the beginning.
Comparing those two numbers is misleading.
The relevant measure is total cost of ownership over a realistic period.
For purchased software, that means more than subscriptions.
Implementation may require consultants. Data needs migrating. Interfaces need creating. Employees require training. Configuration has to be maintained. Additional modules may carry separate charges. Storage, API access, environments or premium support may add cost. User numbers can grow.
The organisation should also consider the internal time required to administer the platform and manage the supplier.
For bespoke software, development is similarly only part of the cost.
Discovery, design, infrastructure, testing, security, support, monitoring, updates and ongoing development all matter.
A useful comparison should therefore consider at least five years where the software is expected to become business-critical.
But even total cost of ownership misses two important measures: change cost and exit cost.
Change cost describes how expensive it becomes to evolve the system.
Requirements will change.
Regulation changes. Businesses reorganise. Products evolve. Customers expect new experiences. Acquisitions introduce new systems. AI creates new opportunities. Suppliers modify APIs. Reporting requirements grow.
The software decision should therefore be evaluated against an uncertain future rather than today’s specification.
Imagine Product A satisfies 90% of requirements today but makes each future change expensive. Bespoke Option B costs more initially but provides an architecture designed for continued evolution.
A traditional business case may favour Product A.
A five-year change model might favour Option B.
This is particularly important where the organisation already knows that its operating model is changing.
Exit cost is different again.
What would it cost to stop using the solution?
For a commercial product, this could include extracting and cleansing data, recreating integrations, rebuilding business rules, retraining users and implementing a replacement.
For bespoke software, exit might mean changing development partners, recruiting an internal team or migrating from particular infrastructure.
Thinking about exit before implementation may seem pessimistic.
It is actually good architecture and good procurement.
Technology dependencies are inevitable. Unexamined dependencies are the problem.
There is another cost that is rarely included in spreadsheets: the cost of organisational friction.
Suppose an off-the-shelf system saves £200,000 compared with bespoke development but causes 150 employees to spend an additional fifteen minutes each day working around its limitations.
At approximately 230 working days each year, that equates to more than 8,600 hours of additional effort annually.
The exact financial value will vary, but the principle matters.
Software economics cannot be understood purely through IT expenditure.
If technology exists to make an organisation more effective, the impact on the organisation itself belongs in the calculation.
The same is true of opportunity cost.
What revenue cannot be generated because the current platform cannot support a new service? How much growth is constrained by manual administration? How long does management spend reconciling inconsistent information? What is the cost of poor customer experience? What risk exists because critical knowledge remains inside spreadsheets or an ageing application?
The cheapest software is not necessarily the software with the lowest licence cost.
It is the software that produces the best overall economic outcome.
The most important step in a build, buy or bespoke decision happens before products are shortlisted and before development is estimated.
Understand the problem.
This sounds obvious, but organisations often enter technology projects with a solution already embedded in the language.
“We need a new CRM.”
“We need to replace the ERP.”
“We need an AI platform.”
“We need a bespoke portal.”
Each statement contains an assumption.
A better starting point is to describe what the organisation is trying to change.
Perhaps customer information is fragmented across five systems. Perhaps employees spend hours re-entering orders. Perhaps the existing case management system cannot support a new regulatory process. Perhaps customers cannot complete a journey without phoning the organisation. Perhaps management cannot obtain reliable operational reporting.
These are problems that can be investigated.
A strong discovery phase should map users, processes, data, systems, constraints and outcomes before deciding what technology form the answer should take.
That process often reveals that the original build-versus-buy question was too broad.
A proposed “new platform” may actually consist of several capabilities with different answers.
Identity can be bought. Payments can be bought. Email delivery can be bought. Document storage may use an established cloud service. A standard CRM might remain.
The distinctive workflow connecting those capabilities could be bespoke.
This approach avoids rebuilding mature technology unnecessarily while preserving control where it creates value.
It is also increasingly important as software development changes.
AI-assisted engineering is improving the speed with which software teams can explore ideas, generate code, test approaches and work with large codebases. This can alter the economics of bespoke development, particularly for prototypes, integrations and well-defined functionality.
But faster code production does not remove the hard parts of complex software.
Understanding users remains difficult. Untangling legacy systems remains difficult. Designing appropriate data models remains difficult. Resolving contradictory stakeholder requirements remains difficult. Making architectural decisions remains difficult. Security, governance, testing and organisational change remain difficult.
If anything, cheaper code makes judgement more valuable.
The organisations that benefit most will not simply be those capable of producing more software. They will be those capable of deciding which software deserves to exist.
That is ultimately what the build, buy or bespoke decision is about.
There is no prize for owning the most custom code.
Equally, there is no inherent virtue in buying everything as SaaS.
The objective is to put ownership, investment and differentiation in the right places.
Buy the capabilities that are mature, interchangeable and non-differentiating when doing so creates genuine leverage.
Build internally where software engineering itself is an enduring strategic capability the organisation needs to own.
Commission bespoke software where unique requirements, integrations, data or operating models justify a tailored solution but specialist external capability provides the most effective route to delivery.
And combine those approaches where the architecture naturally divides between commodity services and distinctive business capability.
Before making a final decision, leadership teams should be able to answer several questions with confidence. What business outcome are we buying? Which requirements genuinely make us different? What compromises are we willing to make? What data and integrations are involved? What is the realistic five-year cost? How expensive will future change be? What happens if the supplier relationship ends? Who owns the product after launch?
If those answers are unclear, obtaining three software quotations will not create clarity.
It will simply put prices against an undefined problem.
For complex business software, the quality of the decision made before delivery often matters more than the technology selected afterwards.
A strong solution is not simply one that meets today’s requirements.
It is one that fits the organisation well enough to create value today, can change when the organisation changes, can be operated and secured responsibly, and does not create dependencies that become tomorrow’s legacy problem.
That may be something you buy.
It may be something you build.
It may be bespoke.
The right answer begins with understanding which parts of your technology should be ordinary — and which are important enough to make your own.
Is your team looking for help with bespoke business software development? Click the button below.
Get in touch