Corporate responsibility

Technology is worth what it leaves behind.

A software company’s responsibility is measured by whose data its code touches, who it leaves out, and what it leaves behind.

We do not treat corporate responsibility as a section appended to the end of an annual report. For a software company, responsibility mostly hides inside everyday engineering decisions: which field gets collected, who can see what, whether the interface can be used with a keyboard, whether a server really needs to be that size. This page is an attempt to write down plainly the limits we set ourselves in those decisions.

Every heading below is a qualitative commitment. We do not write in a certification we do not hold, a carbon figure we have not measured or a donation we have not made; where part of a commitment would need documentary support, we mark that openly until the document is published.

Our commitments

Responsibility under six headings

Each heading rests on a practice we already show elsewhere on the site; the links go there.

Protecting personal data

In every system we build we ask one question first: is this field genuinely necessary? The best data security is data that was never collected. Data minimisation is not a compliance clause to us but a design constraint: every field that collects personal data is recorded during analysis together with its justification, and a field without one never enters the system. Retention periods, deletion flows, the ability to answer a data subject request and the reflection of disclosure notices in the software are all part of the same design.

Read our privacy policy

Information security discipline

Security added as a later layer is both expensive and brittle. We write the access and identity model, the data classification and the separation of duties into the architecture at the start of a project; a secure development lifecycle is not a separate service but the default on every project. Working in client systems we follow least privilege, we do not move production data into a development environment, and we close our access when the work is done.

Information security consulting

Accessibility is a deliverable

We treat accessibility not as a checklist left to the end of a project but as a requirement the interface has to meet from the start: meaningful HTML structure, full keyboard navigation, visible focus states, legible contrast and respect for reduced-motion preferences. The accessibility policy we publish for our own site is the minimum line we work to in client projects as well.

Our accessibility policy

The environmental footprint of software

A system’s environmental impact is decided in its architecture before it is decided by office habits. Pages that grow without reason, scheduled jobs that run for nothing, servers sized without measurement and logs nobody ever reads all consume energy. Sizing infrastructure to the organisation’s real load, setting caching up properly and removing unnecessary work pull in the same direction on both cost and consumption — which is why we treat this as a natural consequence of engineering discipline rather than as a separate campaign.

IT infrastructure consulting

Suppliers and subcontractors

If we source part of a job externally, responsibility towards the client stays with us. Where we use a subcontractor we do not hide it from the client; we pass the same confidentiality, data processing and security obligations on by contract. When choosing third-party libraries and services we review licence suitability and maintenance status, and we do not put abandoned dependencies into a client system.

Our way of working

Conduct and the team

There is no room in the team for discrimination, harassment or bullying; hiring and assessment decisions are made on the competencies the work requires. We see knowledge sharing not as a culture statement but as a sustainability requirement: documentation, code review and handover habits are the standard, so that no system ends up carried by one person alone. We also care about passing on what we learn — internship programmes, university collaborations and openly published technical writing are how.

Careers page

Foundations

Three principles that do not change

The three points we have published on our company page for years; every commitment on this page is built on them.

Sharing what we know

We care about passing on what we learn inside the team: internship programmes, university collaborations and openly published technical writing.

Responsible use of data

In the systems we build, we question whether the data being collected is needed at all. The best data security is data that was never collected.

Software that lasts

Code that can be handed over, documented and tested means the client is not dependent on us. We treat that as the standard, not as a risk.

Accountability

How this page is kept current

We update this page when one of our commitments changes, or when grounds emerge to document one. Every sentence here describes work we do today; we do not add a certification, a figure or a title that is not backed by a document.

If you believe you have found a problem with data, accessibility or security in a system we built, you can write to us directly. We track reports until they are closed and we come back to you. For information about the company generally, see our company page; for the organisations we work with, the our clients page; and for the scope of our services, the solutions page.

[email protected]Contact form