Approach
A method, not a manifesto.
None of what follows is unusual on its own. Holding all of it at once, on every product, without exception, is the part that takes discipline — and it is most of the reason the work comes out the way it does.
- 01
A shared foundation
One codebase, many products
Every product we build is assembled from the same internal framework: one design system, one data layer, one client for everything that leaves the device. A product is the part that is genuinely specific to it, and nothing more. The effect compounds — an improvement to the foundation improves every product at once, and a class of bug can only be fixed once because it can only exist once.
- 02
Replaceable by design
The model is a dependency, not a foundation
No product of ours is built on a single provider, and none of them would notice if one disappeared. Requests are routed across independent vendors and raced against each other; if the leading attempt stalls, a second is already in flight and the first usable answer wins. Model choice is a line of configuration, deliberately, so that a better or cheaper option can be adopted the week it appears rather than the quarter after.
- 03
Contracts, not text
Typed at the boundary
Statistical output is never trusted directly. Every response is decoded against a declared schema before any part of the interface is allowed to see it, and anything that fails to conform is rejected rather than displayed. This is the difference between a product that degrades gracefully and one that shows a user something incoherent. It also means the interesting failure is a validation error in a log, not a support email.
- 04
Locality as a default
On the device first
Personal context — histories, documents, the indexes built from them — stays on the hardware the person owns. Where a product needs to search that context, it searches it locally, using vector indexes that live in its own storage on the device. What travels to our infrastructure is the smallest thing that cannot be computed locally, and it travels because the feature is impossible otherwise, not because it was convenient.
- 05
Attested at the edge
Credentials never ship
No key of ours has ever been inside a binary a user can download. Our software proves its authenticity to our gateway using the secure element in the device itself, and only then receives a short-lived credential. Our gateway, in turn, refuses anything that has not arrived through our own edge. It is more work than putting a key in the binary, and it is the only version of this that is actually true.
- 06
Measured, not estimated
Cost is a design constraint
Every request has a price, and we know what it is per call rather than per month. That number is treated the way latency is treated: a budget the design has to fit inside. It is why our products stay sustainable at the prices we want to charge, instead of needing an enterprise contract to make the arithmetic work.
- 07
Releases we can withdraw
Reversible by default
A release is not a commitment we cannot withdraw. Behaviour is configurable from our side after the fact, so a feature that misbehaves in the field can be narrowed or switched off in minutes, without waiting on a review queue. Combined with the fact that we use everything we build, every day, it means problems are usually found by us and fixed before anyone has to report them.
Questions are welcome.
If you want to know how a particular piece of this works, ask. We would rather explain it than have it taken on faith.