Buying an established platform can accelerate delivery and remove responsibility for commodity capabilities. Building can create a stronger fit around differentiated processes, customer journeys and data. Both can be expensive when the decision is made without understanding the wider operating model.
Build or buy is rarely a binary decision
Most modern digital platforms combine purchased and bespoke capabilities. An organisation might use an established CRM, identity provider, payment service or CMS while developing the workflows and customer experiences that differentiate its proposition.
The strategic decision is therefore not simply whether to build or buy an entire platform. It is deciding which capabilities are standard, which are distinctive and where the boundaries between them should sit.
Poorly defined boundaries create duplication, fragile integrations and uncertainty about which system owns each process or dataset. Well-defined boundaries allow organisations to benefit from established products without allowing those products to dictate the entire digital experience.
Standardise what does not differentiate you
Building commodity functionality rarely creates competitive advantage. Mature commercial products can provide capabilities such as customer records, authentication, payments, document storage and content management more economically than reproducing them internally.
The case for buying is strongest when the organisation can adopt the platform’s standard model without materially weakening its service or operating processes.
The warning sign is a procurement process dominated by demonstrations rather than operational evidence. A platform may appear comprehensive while still requiring extensive adaptation to work within the organisation’s actual technology, data and governance environment.
Build where control creates business value
Bespoke development is most valuable when the capability is central to the organisation’s proposition. This may involve a specialist customer journey, proprietary workflow, distinctive product experience or use of data that cannot be represented effectively within a standard platform.
The justification should not be that the organisation is unique. Most organisations have some unusual processes, but unusual does not necessarily mean valuable. In some cases, the better decision is to simplify the process rather than encode its complexity into new software.
Building becomes strategically defensible when ownership improves the customer experience, creates operational advantage or enables the organisation to respond faster than a supplier-controlled roadmap would allow.
The Salesforce example
Salesforce demonstrates why a purchase decision cannot be assessed through subscription pricing alone. Its established CRM capabilities, configurable data model and wider ecosystem can provide a strong foundation without requiring an organisation to build core customer-management functionality.
The commercial case can become less straightforward as the implementation expands. Different teams may require different licence types, while automation, analytics, artificial intelligence, data services, support and other capabilities may involve higher editions or additional products.
A Salesforce implementation may also need to connect with websites, customer portals, finance systems, marketing platforms, data warehouses and operational software. At that point, the investment includes much more than the core licences.
The relevant comparison is not Salesforce subscription versus bespoke development. It is the total cost and operational impact of the Salesforce ecosystem compared with the credible alternatives.
Licensing changes the economics over time
Per-user pricing can appear predictable during procurement but behave differently once the platform becomes embedded across the organisation. Growth in users, departments, markets and use cases can move the implementation into different commercial territory.
A credible financial model should include:
- core user licences and licence types;
- product editions required for essential capabilities;
- additional modules, storage and usage charges;
- API access and integration products;
- implementation and migration;
- configuration and custom development;
- support, administration and product ownership;
- renewal assumptions and expected growth; and
- the eventual cost of changing or leaving the platform.
These costs should be modelled across several years and under more than one growth scenario. A platform that is commercially attractive at launch may be less attractive once it becomes the system used by several business functions.
Integration is part of the product
Integrations are often treated as implementation tasks rather than long-term product components. In reality, they determine how reliably information moves through the organisation and how easily the platform can evolve.
A Salesforce implementation might synchronise customer and opportunity data with a website, transfer financial information to an ERP platform, trigger activity in a marketing system or supply data to reporting services. Each connection introduces ownership, security, monitoring and support requirements.
API availability may depend on the selected Salesforce edition, and API usage is subject to platform limits. Integration products such as MuleSoft can provide additional capability but also introduce further licensing and operational considerations.
The architecture should establish which system owns each dataset, how conflicts are resolved, how failures are recovered and which team is responsible for the integration after launch. Without this clarity, the organisation can end up with several platforms containing different versions of the same customer information.
Configuration can become hidden customisation
Commercial platforms are most effective when organisations remain reasonably close to their supported patterns. Configuration can adapt fields, permissions, workflows and interfaces without fundamentally changing the product.
The line becomes less clear when layers of automation, custom objects, specialist code and marketplace extensions accumulate. Each addition may be justifiable independently while collectively creating a platform that is expensive to understand and difficult to change.
If a purchased product requires sustained effort to behave unlike the product that was purchased, the organisation should revisit the original decision. A bespoke component may provide a clearer and more maintainable solution than further customisation.
Ownership does not disappear when you buy
Buying software transfers some technology responsibilities to a supplier, but it does not transfer accountability for the business outcome. The organisation still needs product ownership, data governance, supplier management, architectural oversight and a roadmap.
Without internal ownership, platform decisions tend to become reactive. New requirements are solved with another licence, plugin or integration, gradually increasing cost and complexity without improving the overall architecture.
Bespoke products create a different ownership requirement. The organisation controls the roadmap and intellectual property but must maintain the team, documentation and operational capability required to support them.
Time to value needs closer examination
Buying is usually presented as the faster route, but procurement speed and time to value are not the same thing. Contracting, configuration, data migration, integration and organisational adoption can significantly extend delivery.
Likewise, building does not always mean a lengthy programme. A focused product addressing the most valuable part of a journey can reach users quickly and develop incrementally.
The comparison should be based on the earliest point at which the organisation can deliver a measurable outcome, not the date on which the software is purchased or the first release is deployed.
Plan for change and exit before committing
Platform decisions should be evaluated against plausible future changes: acquisitions, new markets, different commercial models, increased transaction volumes and changes to the wider technology estate.
Supplier dependency is not automatically a problem. It becomes a problem when the organisation cannot estimate the cost of change, retrieve its data effectively or replace one capability without disrupting the entire service.
Contracts, data portability, API availability, documentation and architectural separation all affect exit risk. These questions are easier to address before a platform becomes operationally critical.
The best answer is often selective
A strong architecture uses established platforms where they provide leverage and bespoke development where it creates differentiation. For example, Salesforce might manage customer and sales data while a bespoke portal delivers the organisation’s distinctive service experience.
This approach avoids rebuilding mature CRM capabilities while preventing the customer journey from being limited by a back-office platform. It also creates a clearer basis for changing individual components as requirements evolve.
The success of a selective approach depends on disciplined architecture. Systems need explicit responsibilities, integrations need clear ownership and the organisation needs a coherent view of its data.
Make the decision through evidence
A useful build-or-buy assessment should examine the organisation’s operating model, technical landscape, data, user journeys and commercial constraints before recommending a platform.
Shortlisted products should be tested against real scenarios, including difficult workflows and integration requirements. Commercial modelling should reflect likely adoption rather than the smallest viable licence commitment.
The recommendation should explain not only what to buy or build, but also what should remain outside the solution, how the components will interact and what capability the organisation needs to retain internally.
Deciding whether to build or buy?
The right answer may be a commercial platform, a bespoke digital product or a deliberately designed combination of both. The important decision is where standardisation provides leverage and where ownership creates measurable value.
Our consultancy, architecture and development services can help you assess platforms, model licensing and integration costs, define system boundaries and create a practical delivery roadmap.
Explore our digital product and consultancy services
Talk to us about your digital platform
