We own the whole thing, including the running of it.

How we choose what to build

We look for work that is unglamorous, structurally awkward, and currently being done by a person in a spreadsheet. Those three together are a good signal: unglamorous means nobody has crowded the space; structurally awkward means the problem has real shape and cannot be solved by a generic tool; and the spreadsheet means somebody already cares enough to maintain it by hand.

What we avoid is equally deliberate. We do not build things whose value depends on our getting very large very quickly, because we are not going to. We do not build on a platform that can withdraw our access. And we do not start something we are not prepared to still be operating in ten years, since operating it is the part we have committed to.

How we build

• Model the domain honestly, then simplify. The first version of a system should be able to represent what is actually true about the world it describes. Simplification comes after that, by removing concepts, not by never having had them.
• Converge rather than accumulate. When two features turn out to be the same idea, they become one and the older path is deleted. A codebase that only ever grows is a codebase nobody can reason about, and the person who pays for that is the user.
• Design for the person who was handed the job last week. Most software is operated by someone whose actual profession is something else. If a screen needs training, it is not finished.

What we hold ourselves to

Our systems hold other people's records. We treat that as a custodial duty and not a commercial opportunity: encrypted in transit and at rest, production access restricted and audited, and no sale, rental, brokerage or model training on customer data — not as a matter of current policy, but of what the business is. The detail is in our privacy policy.