how-we-work
How we work
A short loop, repeated: define the job, build it to a standard, then release it and keep improving it.
Our process
01
Define
Every product starts with one clear job and the people it is for. We write down what it does, and what it does not do, before we draw anything. Leaving things out is part of the design.
02
Build
Design and engineering work side by side. We build in small pieces that can be tested, and we check each piece against the standards below before it moves on.
03
Release and improve
We publish under our own name and keep working on the product afterwards. Updates are small and regular, and they follow what we learn from feedback, reviews and our own tests.
Innovation, held to a standard
We like trying new things. We try them in small steps that can be tested and undone, and a new tool or technique stays only when it makes something clearer, faster or safer for the people who use it. Whatever we try is built to the same standards.
Accessibility
Accessibility is part of the design brief from the first sketch. We aim for WCAG 2.2 level AA on our websites, and we test with automated tools and by keyboard.
Performance
Speed is part of the design. We set size and speed budgets and test against them, so that a page or a screen is not heavier than it needs to be.
Privacy by design
We start from what a feature really needs to know, and we leave out what it does not. Each product has its own privacy policy, written for that product.
Security
Security is part of the build, not a later step. Our website is served over HTTPS only, and we publish a way to report a security problem.
This website is the first example
It has no cookies, no analytics and no third-party scripts, and its fonts are served from our own domain. Each release is checked against accessibility, speed and privacy gates before it goes live. The cookies page lists the one thing it can store, and the privacy notice says what our host records.