To buy or to build, and what should be considered in the procurement process

Options

It is important to note that while the question is to buy or to build, the answer is somewhere on a scale of different options. The most notable ones are:

• Buy – Ready to Use Software Product (RUSP), Commercial Off-The-Shelf (COTS)
• Configured, not custom
• Low / no-code
• Build - bespoke applications

Note that this is a non-exhaustive list and it doesn’t cover all permutations and combinations, including Government Off-The-Shelf (GOTS), Niche Off-The-Shelf (NOTS) or Military Off-The-Shelf (MOTS).

Buy

Commercial Off-The-Shelf

Let’s start with commercial off-the-shelf.

This is a broad category covering pretty much everything in the traditional software or platform-as-a-service space. COTS is “ready-made”, or canned software (and hardware) which may be adapted after purchase to the needs of a customer or organisation. If the need is standard, there usually is a product on the market.

Most COTS products are "one-size-fits-all", and outside of commodity software, they often provide limited options to fully adapt to your organisation's needs. Adopting the limited options also carries an additional cost. It is also true that many Software as a Service companies will provide a whitelabel option at a premium, enterprise cost.

Ready to Use Software Product (RUSP)

This is a relatively new category introduced by the International Standards Organisation (ISO) to better reflect modern reality. According to the “ISO/IEC 25051:2014 Software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing” standard:
“Ready to Use Software Product (RUSP) are packages sold to the acquirer who had no influence on its features and other qualities. Typically the software is sold pre-wrapped or downloaded via web store with its user documentation. A software product, which a user can use anytime thorough Cloud Computing may be considered as RUSP.”

Think commodity or productivity software such as office suites (text processors, spreadsheets, email), communication applications (Microsoft Teams or Slack as an example), human resources or time management applications.

In many ways, this is a modern superset for COTS.

When is COTS/RUSP the right choice for organisations?

• They need commodity software,
• They have standard requirements
• They are small and have limited resources and capacity

The trade-off is that organisations depend on the supplier roadmap, their security and other compliance areas, as well as cost/pricing strategy. Customisations and personalisation of services and systems come at a premium.

We have often found that outside of the commodity space, big technology COTS/RUSP suppliers will have extremely well-polished demos, but once they are in the building, there is need for significant investment to make it work for organisational needs.

Configured, not custom

This is a bit of a hybrid category, but the premise for it is that systems or products are modular and highly configurable via the user interface. These software packages allow end users (usually with elevated privileges) to mould them to their needs. This is sometimes referred to as modifiable software.

Platforms like Squarespace, Wix, Shopify and to some extent Wordpress and Drupal fall in this category. It is important to note, however, that both Drupal and Wordpress are strongly in the build category too.

These are excellent for getting something up and running in little to no time. You can get a lot of mileage out of them. However, with most products in this category, as with COTS/RUSP, organisations have no influence over the roadmap or cost. And for things at the Wordpress/Drupal side of the spectrum, you are usually better off in the build category to fully meet all your needs.

Low/no-code

Recent years have seen the rise of low-code platforms that started with fulfilling niche needs like automations and integrations between different systems that had no interoperability, and extended to full-on lego-like connectors with different layers of customisation and code logic, allowing folks to build. Think of middleware like Zapier and n8n, or platforms like make.com, OutSystems, Mendix, and Appian.

And while this doesn’t necessarily fit neatly in the space of websites, low/no-code platforms fulfil certain aspects of modern websites, such as form creation and handling. Think of newsletter signup on the simple side and, on the more complex side, full-on integration with various systems like CRMs.

While most are cloud-based, some like n8n provide a self-hosted option, helping to avoid lock-in.

In our experience, low/no-code platforms can be a powerful service power-up and augmentation. For example, using OutSystems allowed us to build a replacement trainee management system for NSHCS using an iterative approach, with immediate interactivity that offered a more realistic experience for users, leading to more detailed and actionable feedback. Based on our insights so far, we will go as far as suggesting that a lot of case management requirements are ultimately commodity needs strung together, which lends itself to low/no as a halfway house - the commodity benefits of COTS with the modularity and configurability of a “small pieces, loosely joined” architectural philosophy.

Build

This is the option where organisations have full control of a product or system’s lifecycle. It is the “à la carte” option, where you get to choose the exact features you need, built to specification.

A bespoke product can be built or assembled using fully closed source code, fully open source code, or a mix of both. Our preference, and the GDS service manual recommendation, is to use open source. Not only can you have a say in shaping features and the roadmap, you’ll also benefit from the community around it:

• Peer-to-peer support and knowledge sharing
• Active maintenance
• Extensions from a wide and diverse user base
• Contributions covering a range of use cases
• Avoids vendor lock-in.

This is one of the reasons why we open-sourced Wagtail CMS, after building a content management system for the Royal College of Arts, and it took on a life of its own.

Building a product also means you have much more granular control over its features, have flexibility around integrations, the pace of change and priorities. The trade-off is that there is usually a higher initial cost, and you need the skills and expertise for support and maintenance.

It is important to note that Build doesn't necessarily mean starting from scratch, or with individual pieces of Lego. It also means reusing existing open source components that avoid wheel reinvention. For example, as we work in Python/Django when we do bespoke builds, when we need to integrate with an identity provider (IdP) like MS Entra ID (formerly known as Azure Active Directory), then we're going to use a third-party open source component to speed things up and reduce cost.

We found that taking this to the next level and working in the open, and open-sourcing the end result, often leads to easier sharing and re-use, thus amplifying the benefits of building. In our case, the work we did on the Cambridge University Hospitals intranet and Children’s Health Ireland intranet provided a solid foundation for the Guy’s and St. Thomas’ intranet, allowing us to focus on bespoke needs and requirements. Another example is LocalGov Drupal, where a few councils pooled resources together towards building an open source product that is now used by many more.

Factors

In addition to the options and trade-offs outlined before, there are a number of factors one needs to consider when making a decision on which way to go.

Applicability and scope

Is this a foundational system, i.e. a good amount of your business relies on it? Is it a "commodity" system, like an office suite? Does it require interoperability? Do you have the resources and knowledge to build your own?

COTS or RUSP are usually the better choice for foundational or commodity systems (e.g. office suite, authentication and interoperability). And, depending on the size of the organisation, platforms that power their web presence too.

It is worth noting that when we say COTS/RUSP, we don't mean they should be things coming from behemoths like Microsoft or Google. There are more and more alternatives, both commercial and open source. For example, Nextcloud or Zoho instead of the Google or Microsoft suites, Jitsi instead of Zoom, Element over Slack and so on. There is also a growing digital sovereignty movement in Europe aiming to untangle from a heavy US-centric dependency and gain suitable privacy and security within European law and policy boundaries. As an example, Airbus moved critical applications off Amazon Web Services to Scaleway, a French provider.

On the other hand, if you have quite specific requirements, integrations, a design system and more, and want full control over your setup, build is the way to go.

Change velocity

Change velocity refers to how fast a product or platform evolves. At one end of the spectrum, you may be locked into something that hasn't been meaningfully updated in years, leaving you to deal with obsolescence, unpatched vulnerabilities, and a shrinking pool of expertise. At the other end, something that changes drastically every quarter can bring its own burden and ongoing overhead of constant relearning, breaking changes, and simply keeping pace.

A key part of evaluating whether a product or platform is the right fit is understanding where it sits on this spectrum, and what that implies for your organisation's capacity to adapt, maintain, and plan long-term.

Roadmap and ability to influence it

One of the mistakes we often find is that organisations do not consider roadmaps, and do not ask themselves “what is the product roadmap?”, “how does it align with our organisational needs?”, and “can we influence it at all, or are we at the provider’s mercy?”

With COTS/RUSP, most organisations have little to no control over the roadmap. For example, at one point, we were using Monday.com for ticketing and they did not support markdown or code blocks without additional hoops and third-party apps. We waited way too long, and luckily switched to something else better geared for software development.

On the other hand, organisations have full control over the things they built either themselves or with a partner. And, if they chose open source components or software, they can contribute or sponsor specific features or bug fixes and help shape their roadmap.

Vendor lock-in

One of the concerns with commercial software is vendor lock-in, especially on large projects, both on infrastructure and software and their complex intertwining. A platform that you cannot leave introduces financial and operational risks, and may tie you to a limited number of suppliers for ongoing maintenance and support.

Unless organisations are choosing an incredibly niche technology stack, bespoke development removes that barrier and brings the choice of switching suppliers from a wider ecosystem. As an example, Wagtail has a strong community that builds on the broader and well-established Django one. There are hundreds of suppliers of developers around the world who build and support Wagtail sites. In the Django community, there are hundreds of thousands of developers, and many of them have worked with or can pick up a Wagtail project. Furthermore, according to JetBrains surveys, there are well over 11 million Python developers.

Total cost of ownership (TCO)

This is an important aspect, especially in the non-profit sector and smaller public bodies or local government. There are different lenses that one can look at the total cost of ownership (or TCO), and its full shape will depend on the given product or system.

To start, organisations should always consider the initial costs. This includes licenses, be it one-off or per user, followed by setup, installation and configuration or the cost of development. Add infrastructure setup costs if using an on-premise or a managed model. One must factor in any transition costs – be it data and content migration, or process changes, as well as staff training.

Following that, there are different ongoing costs. From license or seat costs, to ongoing support and maintenance covering bug fixes, new features, security updates or version upgrades. Additionally, there could be infrastructure costs, recurring security audits and penetration tests, regular business continuity plan updates and disaster recovery training and simulations.

Last, but not least, the different costs should be weighed against the product life-cycle, or in other words, how long the system or product is expected to last before replacement is needed.

COTS tend to have more predictable and lower costs upfront, but then a lot of one’s budget is likely to go on licenses rather than improvements. Whereas bespoke implementations will likely have a bigger upfront cost, but a typically lower ongoing investment (even if it is in the form of regular updates).

If you have a small budget and don't need customisations, COTS is often better. However, if you have specialised needs or want a solution that evolves with your business needs, then you want to build.

Security

This is an important consideration. Multiple governmental agencies recognise that security is a serious risk of using COTS software. While it depends on the vendor and application, more often than not, they can be slow to respond to vulnerabilities. And the ripples of unpatched vulnerabilities or compromised data are significant.

On the other hand, custom-built doesn't necessarily mean secure, especially if done cutting corners, but generally the track record is much better.

In our experience, while not perfect, open source tends to have a much stronger security positioning, strengthened by collective knowledge and community effort. Working in the open and using open-source brings up a lot more scrutiny, can surface issues earlier, and strengthens the overall product. In fact, the UK government recently published additional guidance around open code that further supports this, and the principles outlined in the Service Manual and the Technology Code of Practice. That is, the need to work in the open and use open source where possible.

So, to buy or to build?

Before you can answer that, start with a Discovery phase every single time. Especially if you are in a rush to get off failing or legacy technology. Investing in discovery will help clarify what you actually need from a functional, operational and technical point of view. Research with your users and staff to learn how the different systems work today, and where they break down. Map the journeys end to end, review your integrations, current technology and data to establish what can be reused, integrated with, or replaced. In our work, we look at different pieces together to understand the hidden complexities and design services and their technical architecture together, so usability and feasibility are weighed side by side.

The result will be an evidence-based view of the challenge, a shared understanding of the different complexities and priorities, and an informed means to make the right decisions to choose the right tools for the job – e.g. to improve staff efficiency and overall user experience, rather than replacing like with like.

We believe the stronger answer is layered. Buy or configure a proven product for the commodity parts: be it office suite, CRM, booking / ticketing, email marketing, or hardware. Build only what makes your organisation distinct, with workflows designed around your team, operating environment, and community. Join it all together with secure, open integrations and relevant data standards so data flows between systems, reducing the risk of lock-in. And where possible, share and collaborate with the wider community for greater effect.