How we build
Most software fails long before the code does — in the choice of problem, in the scope, in the willingness to keep going after launch. These are the working rules we hold ourselves to, written down so they can be argued with.
01
A product earns its first sentence before it earns its first screen. If the problem cannot be stated plainly, no amount of feature work will make the result feel coherent. We would rather ship a narrow tool that is obviously right than a broad one that is vaguely useful.
02
Installs are easy to buy and easy to lose. The measure we care about is whether someone opens the app again next month, without being reminded. That standard changes what gets built: fewer surfaces, faster paths, less to learn on the second visit.
03
How a product is found, described and priced is a design problem, not an afterthought handed to someone else once the build is finished. The listing, the first run and the upgrade moment are all part of the same object.
04
Engineering foundations, design language, release process and analytics are shared across the portfolio so each new product starts further along. What is never shared is the personality: each app is allowed to look and behave like itself.
05
We operate what we launch. A product that stops being maintained stops being worth keeping, so the plan for year three matters as much as the plan for launch week. Nothing here is designed to be abandoned.
A product should be easy to explain because the problem it solves is precise.
About the studio