How we build

Seven stages, in order

The stages are numbered because the order matters. In reality they overlap and loop back, but none of them is skipped.

1. 01

   Define the problem

   Work starts with a written problem statement: who has the problem, what they do today instead, and what would have to be true for a piece of software to be a better answer. We look for evidence that the problem is real and persistent rather than merely interesting to us. If the statement cannot survive a few hours of argument, nothing is built.

2. 02

   Narrow the scope

   We then decide what the thing will not do, and write that down alongside what it will. Scope is set by what we can build well and operate sustainably, not by what is technically possible. A narrow first version that is genuinely finished teaches us more than a broad one that is permanently almost ready.

3. 03

   Design

   Interface design happens against real content and real constraints, not placeholder text. We work through the whole journey, including the empty states, the error states and the parts that are inconvenient to draw. Accessibility is part of this stage: color contrast, focus order, text sizing and assistive-technology behavior are decided in the design, not retrofitted after.

4. 04

   Engineer

   We build on the platform's own conventions rather than a house abstraction layered over them, and we keep the number of dependencies small enough that we can account for each one. Data handling is designed before it is implemented: what is collected, where it is stored, how long it is kept and what happens when it is no longer needed. Code is written to be read by whoever maintains it next.

5. 05

   Test

   Automated tests cover the behavior we are unwilling to break, and they run on every change. Beyond that we test on real devices under real conditions, because a clean result on fast hardware and a good network says very little. We test the failure paths deliberately, including bad input, lost connectivity, interrupted operations and denied permissions.

6. 06

   Operate

   We run the infrastructure behind our applications ourselves rather than leaving it to someone else's default. That means deliberate deployment, useful logging and monitoring, tested backups, and a plan for restoring service that has been rehearsed rather than assumed. Security work continues here: dependencies are updated, access is scoped, and reports from outside are handled through a published policy.

7. 07

   Maintain

   A release is the start of the work, not the end of it. We aim to keep applications current with their platforms and fix what is broken, for as long as a product is worth that investment. If something is discontinued, we say so directly and give people a way to get their data out where that is practical.

What we hold ourselves to

• Accessibility. Interfaces are built to align with WCAG 2.2 AA: sufficient contrast, visible focus, keyboard operation, respect for the user's text size and motion preferences, and real support for the platform's assistive technologies.
• Privacy by default. A feature collects only what it needs, and data is not kept without a reason.
• Security. Threat modeling before implementation, secure defaults, least-privilege access, routine dependency updates and a published disclosure policy so that anyone who finds a problem can tell us.
• Performance. Measured on ordinary devices and ordinary networks, not on the fastest hardware we own. Responsiveness, memory use and battery cost are treated as features.
• Platform fit. Native conventions per platform for navigation, input, typography and system integration, so an application feels like part of the device rather than a page inside it.

Read more about the company, review our vulnerability disclosure policy or get in touch.