New Feature: Catapult's Latest Article in Connectivity4IR
When enterprise software starts holding the business back, the answer is not automatically to replace it with a custom-built system. The more useful question is whether the capability is standard to your industry or genuinely central to how your organisation creates value.
Packaged enterprise software can be an effective way to support common requirements such as finance, HR and CRM. But it can become a constraint when a business-critical workflow has to bend around the product, integrations become difficult or changes depend entirely on a supplier’s roadmap.
Craig Cook, Principal Engineer at Catapult CX, explored this choice in his 2024 article for Connectivity4IR. The underlying principle remains useful: buy where the capability is standard; seriously evaluate building where the software enables something distinctive. The difficult part is recognising which situation you are actually in.
When enterprise software becomes a constraint
An enterprise system does not have to fail outright to limit the business. It may remain stable and supported while creating delays, workarounds and unnecessary dependencies.
- Teams work around the system. People export data, maintain parallel spreadsheets or duplicate tasks because the packaged workflow does not reflect how the organisation operates.
- Changes are difficult to make. A new customer need or business rule depends on a vendor release, extensive configuration or a costly extension.
- Integration costs keep increasing. Essential information must pass between disconnected products, creating manual reconciliation and fragile interfaces.
- Customisation obstructs upgrades. Modifications made to fit the business can increase testing, support and version-upgrade effort.
- The product restricts differentiation. A capability central to the customer experience cannot evolve at the pace or in the direction the business needs.
These symptoms should trigger a diagnosis, not an automatic replacement decision. Sometimes the constraint is the configuration, an integration or the process itself. Catapult’s legacy software modernisation versus replacement guide covers what to do when an existing system is no longer fit for its role; the question here is whether a particular capability should be bought or built.
Build vs buy software: what is the real decision?
A build-versus-buy software decision compares the value and lifetime obligations of using commercial off-the-shelf (COTS) software with developing a capability specifically for the organisation. The choices are not limited to an unmodified SaaS subscription or a completely bespoke application.
There are several routes: adopt a standard product; configure it within supported limits; integrate it with other systems; develop a focused custom capability alongside it; or build a product that the organisation owns and must continue to maintain.
The decision should start with the business capability rather than a preference for a particular technology. Ask which parts of the process every comparable organisation performs, and which parts create meaningful difference for your customers or operating model.
When buying enterprise software makes sense
Buying is often the better decision when the requirement is well understood, broadly standardised and adequately supported by existing products. Payroll, routine expense management and many HR processes are common examples.
A suitable product can provide established features, security and support, a vendor-maintained roadmap and a faster starting point than building an equivalent system. That advantage depends on the product actually meeting the need without extensive adaptation.
Before committing, test more than the demonstration. Examine the real process, integrations, data portability, licensing terms, upgrade path, accessibility, support model and restrictions on future change.
If the business has to recreate its distinctive operating model inside a rigid packaged product, the lower initial price may prove misleading.
When custom enterprise software makes sense
Custom development becomes more compelling when the application supports a capability that is strategically distinctive, changes frequently or cannot reasonably be delivered through existing products and supported integrations.
That might involve a specialised customer journey, unusual business rules, a critical operational workflow or a service that relies on proprietary data and expertise. The case is strongest when the difference matters to users and can be measured, not simply when stakeholders dislike the existing interface.
Custom software gives the organisation more control over priorities, functionality and integration. It also introduces responsibilities for design, development, security, hosting, accessibility, documentation, operations and continuous improvement.
A bespoke system should not be selected because it seems more flexible in theory. It should be selected because that flexibility addresses a sufficiently valuable problem to justify ownership over the application’s lifetime.
As Martin Fowler explains in his discussion of package customisation, standard capabilities are often better served by a package, whereas strategically distinctive capabilities may justify custom software.
The cost of excessive customisation
One of the most expensive outcomes is buying a standard product and then altering it so extensively that it loses the benefits of being standard.
Extensions, bespoke business logic and unsupported changes can create dependencies on specialist suppliers, complicate upgrades and make new releases risky. The organisation may end up paying for a packaged product while also carrying significant custom-development costs.
Configuration is not inherently a problem. Nor is integration. The question is whether the changes use supported extension mechanisms, can be maintained safely and are proportionate to the business value they create.
Where only one workflow is genuinely unique, building a focused component connected through a stable interface may be preferable to rebuilding the whole platform or heavily changing the underlying package.
This is why a build-versus-buy assessment should include a third option: buy the commodity capability and build only the differentiating part.
A practical build vs buy decision framework
A CIO or CTO can use the following questions to structure the decision. These are decision prompts, not a formula that guarantees a particular answer.
| Question | Buying tends to fit when… | Building becomes more credible when… |
|---|---|---|
| Is the capability distinctive? | It is a common business requirement | It creates measurable customer or operational advantage |
| How closely does a product fit? | Supported configuration meets the real workflow | Critical requirements need extensive workarounds |
| Who controls the roadmap? | Vendor priorities are acceptable | The organisation must control frequent changes |
| What integration is required? | Standard interfaces meet the need | Unique workflows or data models are central |
| What is the ownership capacity? | The organisation prefers vendor-operated capability | It can fund and govern an ongoing product team |
| What is the route to evidence? | A product trial can validate fit | A prototype can test the differentiated hypothesis |
Do not treat one row as decisive. A distinctive feature may still be delivered through a vendor’s supported extension model; a standard capability may have unusual compliance or integration requirements. Weight the criteria by actual business impact and risk.
Compare the full cost of ownership, not just the purchase price
A build-versus-buy business case should compare costs over a realistic planning period, including the resources and constraints the organisation will inherit.
| Cost or obligation | Buying / configuring | Building custom software |
|---|---|---|
| Initial delivery | Evaluation, licensing, configuration, integration, migration | Discovery, design, development, testing and deployment |
| Ongoing operation | Subscription, support, configuration, integrations | Hosting, support, monitoring, security and product management |
| Change and upgrades | Vendor roadmap, upgrades, extension maintenance | Engineering changes, dependencies and technical maintenance |
| Exit and dependency | Data export, contract exit, vendor switching | Code, documentation, skills and platform dependencies |
| Opportunity cost | Time spent adapting processes or waiting for features | Time and funding diverted from other priorities |
The lower initial cost is not necessarily the lower lifetime cost. Nor does owning source code mean the organisation is free from dependency: custom systems can be just as difficult to change if documentation, skills and product ownership are neglected.
AWS’s build-versus-buy analysis makes this point through opportunity cost and the risks that accompany both choices. A credible business case should estimate uncertainty rather than invent precise savings.
Prove the case before committing to a large programme
The most expensive decision is often one made before the organisation has tested its key assumptions. Procurement demonstrations may hide workflow gaps, while a specification for custom software may describe a solution users do not actually need.
Start with the narrowest valuable capability. Agree the user problem, map the real workflow, identify non-negotiable controls and decide what evidence would change the investment decision.
Where custom development is being considered, a working prototype or proof of concept can test usability, integration, technical feasibility and stakeholder assumptions without committing immediately to a large build.
A prototype is a means of deciding what to do next. It is not a substitute for production engineering, security, operational support or clear product ownership.
Catapult’s Modernisation Readiness Review is also designed for architecture uncertainty and build-versus-buy decisions. Its purpose is to diagnose the actual constraints and evaluate options before substantial investment.
If you build, treat the software as a product, not a project
Craig Cook’s original argument in Connectivity4IR makes an important point: a custom application can become tomorrow’s legacy system if the organisation treats delivery as a one-off project.
Launching version one is only the beginning. The product needs a named owner, a maintainable architecture, appropriate tests, security controls, operational monitoring, support and a prioritised roadmap informed by user feedback.
An incremental approach allows the organisation to deliver an initial useful capability, learn from real users and improve it as the business changes. It also creates opportunities to stop or change direction if the expected value does not materialise.
Whether development is delivered by an internal team or a partner, insist on a clear plan for code ownership, documentation, handover, ongoing support and future enhancement. Otherwise, custom development simply exchanges vendor dependency for a different form of lock-in.
What should a CIO or CTO do next?
If enterprise software is constraining the business, avoid framing the choice as “replace the package” versus “build everything ourselves”. First identify the requirement that is genuinely different, the cost of preserving the current process and the capability the organisation needs to control.
- Buy where a standard product meets the need at acceptable lifetime cost and risk.
- Configure or integrate where supported extensions solve the gap without creating excessive complexity.
- Build selectively where a distinctive, high-value capability cannot be delivered appropriately by existing products.
- Validate first when the value, integration or delivery risk remains uncertain.
For organisations already operating a constrained platform, Catapult’s Modernisation Readiness Review can help determine what should be retained, configured, integrated, rebuilt or retired before a large commitment is made.
Media acknowledgement: This is an original, expanded Catapult CX article informed by the perspective shared by Craig Cook, Principal Engineer at Catapult, in “Is your enterprise software holding you back?” published by Connectivity4IR on 14 October 2024. The earlier feature is separately published and is not reproduced here.
