Skip to main content
Guidance

Share, reuse and collaborate

Before building something new, find out whether government has already solved this problem, and make it easier for others to reuse what you build.

Updates to this page

From:
Government Digital Service
Published:
6 November 2017
Last updated:
29 October 2026
Show all updates

  1. Major updates, including removing CDDO as a supporting organisation, removed references to spend controls, and implementation of new content structure.

  2. Remove GOV PaaS and update communities

  3. Addition of a temporary research survey to get user feedback on the Technology Code of Practice.

  4. Restructure and clarification of content. Some link updates and changes.

  5. First published.

Point 8 of the Technology Code of Practice (TCoP) explains how you should look for existing government technology, data and services to reuse or build on, and to make your own work reusable by others.

Why you should share, reuse and collaborate

When you work in isolation, you risk building a solution for a problem which has already been solved elsewhere. You should always ask if what you’re looking for already exists in government, and you should design your solution so that other teams can easily find and reuse it.

Duplicating work across government wastes time and money. Reusing and sharing technology benefits everyone.

What good looks like

You have successfully met this principle if:

  • you’ve systematically checked what already exists before starting to build by looking at the published API Catalogue, relevant communities, and common government platforms
  • you’ve joined or checked in with a relevant cross-government communities before starting significant work, which is especially valuable if you’re part of a smaller team or a subject matter expert (SME) without an existing network to draw on
  • you’ve considered whether a shared government resource (either digital or physical) meets your need before procuring or building your own
  • you’ve built something with potential for wider reuse, and have made it discoverable to other teams - for example, by publishing it in the API Catalogue

How to apply this principle

To successfully reuse, share and collaborate, you should always scale the depth of your pre-build check with the size and risk of what you’re building.

For example, a lightweight look at communities and existing platforms is proportionate for small or highly context-specific work, but a fuller systematic check (which includes the API Catalogue and a market scan) matters more for anything with significant reuse potential across government.  

If you find that you do need to build something new, this is when you should consider whether your solution should be made reusable for others who face the same problem.

Ways to find and reuse what already exists

There are many useful resources within government you should use to help you make informed decisions about building, reusing, and sharing.

Communities

Joining a cross-government community is often the fastest way to find out what others have already built, especially if you’re new to government or don’t have an existing network.

These include the:

APIs

The API Catalogue is the systematic way to check what APIs already exist across government.

If you’re building your own APIs, you should refer to the API technical and data standards and API design guidance to ensure they meet the standards for government APIs.

Government platforms

You should always check whether a common government platform already meets your need. These include:

Common technology and shared infrastructure

You should reuse shared infrastructure rather than building your own where possible. Consider:

Contact us

If you have any questions or feedback, email publicsector.architecture@dsit.gov.uk.

Next: Technology Code of Practice point 9 - Integrate and adapt technology

Sign up for emails or print this page

Contents