Skip to content
We are always hiring


This article outlines the accepted current technical stack. If your project is implemented with these technologies, there is a good chance across the business we have the knowledge to operate and maintain it. This promotes shared code ownership, as defined in our charter.

Deviations from this stack are totally acceptable, but there needs to be justifiable cause.

You may need a technology not available here, or perhaps it is time to experiment with a new approach. That is OK as long as you build consensus that deviating from the usual stack is the right thing to do. Some questions to satisfy when making this decision are:

  1. Risk: For example, am I swapping out the main DB technology serving most of our traffic or just experimenting on a new feature for a handful of users?
  2. Real ROI What potential does the new approach really have over the old? Is there likely to be a good return on us having to learn a new technology given its promised benefits?
  3. Grass is not always greener: Are we just trading the current known limitations of our existing approach for a new set?
  4. External adoption: If we hit problems is there a community of other users and even vendors to help us? If something has wider traction that’s a good sign. Leave pioneering brand new technology to Google and Facebook, instead let’s trailblaze for our users.


We are committed to the following principles for our service and application stacks:

  1. We adopt an API-first approach, where services and applications are delivered via well-documented, public APIs
  2. Applications should typically be implemented as single-page-applications
  3. Shared functionality should be delivered either via libraries or microservices
  4. Prefer AWS cloud-native solutions over self-managed solutions
  5. We should strive for a consistent experience across all environments, from local development through to production.


We have strong cross-team skill base in Javascript, Typescript, PHP, and Java.

We have a number of single-page applications built in Angular1 and React2, and some older applications built in AngularJS3. We prefer Redux4 for state management. We operate a design system based on Bootstrap5 to keep our interfaces consistent and accessible.

Application backends and APIs should be based around appropriate, widely-adopted web-frameworks. APIs should be documented and - wherever possible - public.

Our databases include MongoDB6, PostgreSQL7, and Redshift8. We supplement these with search services in Elasticsearch9, and caching services based on Elasticache10.

We make heavy use of Docker11 to ensure consistency of experience across environments. We aim for our older services and applications to be deployed via Kubernetes12; newer services are more likely to use cloud-native components. All of these are deployed into AWS13.

Underpinning all of this, we employ other technologies and services for operating and monitoring our applications and services.