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.
How we work
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.
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.
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.
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.
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.
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.
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
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.
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.
Credentials rotate, permissions start at zero, and no one merges their own security-relevant change. The interesting failures are almost never the exotic ones.
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
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.