How we work

We would rather be specific than impressive.

A short account of how work actually gets done here — the parts that are unusual, and the parts we hold to when it would be easier not to.

The model

We take equity in what we build, not invoices for hours.

When the product is your own, nobody pays you for the work that did not land. Every decision downstream of that — what we start, how long we are willing to spend on foundations, when we are prepared to kill something — follows from where the incentive sits.

01

Problems with a clock on them

We look for markets where the current approach is becoming illegal, uneconomic or obsolete, and where the replacement has not been built. A deadline set by a regulator or a model release is more reliable than one set by a roadmap, and it means the market arrives whether or not we are early.

02

The hard part goes first

Before there is a brand, a landing page or a launch date, there is a working answer to the question the product depends on: can this match reliably, can this rank without a behavioural profile, can this sync on a bad connection. If the answer is no, we would rather know in month one.

03

Production early, and permanently

Each platform runs live with real users long before it is complete. Staging environments tell you the code compiles; production tells you whether the product is true. We accept the discomfort of shipping something unfinished to avoid the much larger cost of shipping something untested.

04

Privacy decided at the schema

Data minimisation is an architecture, not a policy document. We decide what a system is structurally incapable of storing before we decide what it does, because a guarantee enforced by the database survives staff turnover and a promise in a privacy policy does not.

05

Shared foundations, deliberately

Authentication, storage, deployment, observability — built once, maintained centrally, inherited by everything. The structure only earns its overhead if the fourth product is meaningfully cheaper to build than the first.

06

We kill things

A company with four products and no discontinued ones is not being honest about its hit rate. When the evidence says a direction is wrong we stop, write down why, and move the engineering somewhere it compounds.

Standards

What has to be true before we ship.

Performance

It works on the phone most people actually own

We build for mid-range Android on an unreliable connection first, because that is the device our markets are on. If it is fast there, it is fast everywhere.

Accessibility

Keyboard, screen reader, contrast — not a later ticket

Accessible markup is cheaper to write than to retrofit, and a product that excludes people is a smaller product. It is treated as part of done.

Security

Least privilege by default, reviewed by someone else

Credentials rotate, permissions start at zero, and no one merges their own security-relevant change. The interesting failures are almost never the exotic ones.

Operability

If we cannot see it, we do not ship it

Logging, tracing and alerting land with the feature rather than after the first incident. A system you cannot observe is a system you cannot honestly claim to run.

Start a conversation

Everything we build, we own.

The conversations we find useful are quite specific: investment, distribution and integration partnerships, and people who want to build these products with us. If you are on that list, we would like to hear the specifics.

Contact us For investors