Mobile utility software
We build focused mobile utilities designed to do one thing well — and stay out of the way while doing it.
— Boundaries
We don't build what we don't understand.
Every utility we work on starts with genuine category knowledge — how it behaves across devices, what edge cases exist, where existing tools fall apart. We don't take on a category to learn it on the user's time.
We don't ship half-finished features.
A tool with one reliable function is worth more than one with five unreliable ones. If something isn't ready for real-world use, it doesn't ship — not as a beta, not as a preview, not as "coming soon".
We don't optimise for engagement over usefulness.
Metrics like daily active users or session length can be gamed at the cost of the person using the app. We measure success differently: does the tool do what the user needed, and does it stay out of the way afterward?
We don't take on more than we can do properly.
Growth for its own sake produces mediocre work at scale. We'd rather maintain a small portfolio of well-built utilities than a large one held together by shortcuts. Saying no to the wrong project is part of the craft.
— How we operate
01
Asynchronous by default
We don't equate presence with progress. Our workflow is built around written communication, deliberate reviews, and decisions that hold up without a meeting to explain them. Slow communication, fast execution.
02
One focus at a time
Context switching is a tax on quality. At any given time, one project has our full attention. This means fewer deliverables per month — and each one built with the care that only undivided focus allows.
03
Maintenance is the work
Shipping is the start, not the finish. Every utility we release has a plan for OS updates, edge-case fixes, and performance regressions. We treat post-launch support as a first-class part of the project, not an afterthought.
— Stack
Chosen for long-term support and minimal surprises — technologies we know well enough to move fast without cutting corners.
— Process
Research
Understand before you build
We spend time in the category before writing a line of code. That means using competing tools, reading reviews, mapping the gaps, and knowing exactly which problem we're solving — and which ones we're deliberately leaving alone.
Design
Scope it to what matters
The design phase is mostly about subtraction. We test every proposed feature against a simple question: does this help the user finish the task, or does it exist to make the app look capable? Everything that fails that test gets cut.
Ship
Build for the OS update after next
We write code assuming it will need to survive two major iOS versions without a full rewrite. That means clean architecture, minimal third-party dependencies, and regression tests for every path that matters. Stable by design, not by luck.