How we build.
Four principles that decide most of the arguments before we have them. They are not aspirations — each one is visible in the products we have already shipped.
Privacy is a design constraint, not a policy page
We decide what data a product may hold before we decide what it will do. That ordering matters: it is the difference between a product that collects everything and writes a policy to cover it, and one that never had the data in the first place.
In practice, we hold the minimum that makes a feature work, derive what we can and discard the raw inputs, put expiry dates on anything we keep, and never sell customer data. Where a product can answer a question without storing anything at all, that is the version we build — even when it is harder.
Deterministic first, AI thin
The interesting part of most software is the analysis, and analysis should be reproducible. So our products do the real work in ordinary, testable code: statistics, rules, thresholds, comparisons. Given the same inputs, they produce the same outputs, every time, and we can point at the line that made the call.
Large language models earn their place at the last mile — turning a result into language a non-specialist can act on. Keeping AI thin makes products dramatically cheaper to run, keeps them explainable when a customer asks "why did it say that?", and means a model outage degrades the wording rather than the product.
Ship small, measure in production
We release narrow changes often, behind flags and experiments where it matters, and let real usage settle disagreements that would otherwise burn a week of meetings. Small changes are easier to review, easier to reverse, and much easier to attribute when a number moves.
The corollary is that we instrument before we launch. A feature that cannot be measured cannot be improved, and it usually cannot be honestly justified either.
Own the stack you depend on
We run our own infrastructure and we expect to understand every layer of it. Not because building everything is virtuous — we use managed services heavily — but because a team that cannot explain its own architecture cannot debug it at 2am, and cannot make an informed decision about cost, latency, or where customer data physically sits.
The same instinct applies to dependencies. Every third-party service is a liability as well as a leverage point, so we take on few of them and know exactly what each one would cost us to replace.
See it in a real product
Metricstab is the clearest expression of all four: deterministic analysis, a thin AI layer for explanation, strict data retention limits, and infrastructure we run ourselves.