// /work
The work.
Six categories, three stages, a short stack, four principles. Each described below the way we would describe it on a first call.
/ 01 — what we build
Six categories we ship in.
- 01
Cleaners.
Photo and storage cleaners that do one kind of cleanup per release.
Cleaners that find duplicate photos, large videos, and forgotten downloads — without overstepping the photo library, without inflating the number, without running a fake sweep animation on an empty cache. Each app does a single kind of cleanup well and tells the user the truth about what it found.
- 02
VPN.
Lightweight tunnel apps designed to be forgotten once turned on.
VPN apps for everyday browsing on a phone. Connect, stay connected, never need a settings excursion. There are no dashboards in our VPN apps because nothing on a dashboard would still be true ten minutes from now. The product surface is one toggle and one indicator. The rest of the work is invisible.
- 03
Scanners.
On-device document scanning, returned as clean PDFs.
Camera-driven tools for documents, receipts, and codes. Edge detection done right, OCR where it earns its weight. The user owns the file and the file leaves with them — no nudge to subscribe to keep the scans they just made, no cloud-stored archive opt-in.
- 04
Converters.
Files in, files out. The original stays where it was.
Image, audio, document. The user drops a file, picks a format, gets back a file. We do not delete the source to look efficient and we do not enrol the user in a recurring subscription to keep their own outputs. Conversion finishes in a tap; the original stays.
- 05
Privacy utilities.
Small apps that respect the data they touch.
Apps that do their work on-device when they can be, and label every off-device call by hand when they cannot. We treat 'analytics on' as a code smell. The user can diff network activity if they care to. We are careful never to claim guarantees we cannot defend.
- 06
Battery & device.
Honest readouts, surfaced the way an engineer would describe them.
Battery health, storage breakdown, what the device is busy doing right now. We refuse to build a 'boost' button. Phones do not get faster from a button, and shipping one would be a small lie that compounds across the years a user keeps the app installed. The work is in earning trust through accurate numbers.
/ 02 — how we work
Listen. Sketch. Ship.
Three stages, in order. Each finishes the previous one before the next one starts.
- I.
Listen
We start every engagement with a written brief and one long, uninterrupted conversation. We are trying to understand what the actual category looks like — not what a slide deck would make it sound like. The first session is unbilled and ends with a written framing letter.
- II.
Sketch
A short, deliberate prototype loop. Usually a week. We decide what stays and, more importantly, what gets cut. Most things get cut. The prototype is the artefact a publishing partner can react to before any commitment is made.
- III.
Ship
Submit, watch real usage, refine. The first release is the start of the work, not the end of it. We expect to be embarrassed by version one and reasonably proud of version four. Every release is on a written cadence the partner can plan around.
/ 03 — stack
Tools
we trust.
A short, deliberate kit. Anything outside of it has to earn its place — and most of the time it doesn't.
— anything not listed: ask anyway.
/ 04 — manifesto
Four lines we work by.
Native, on purpose.
We ship native iOS and native Android because phones are not browsers. Cross-platform UI looks fine in a demo and worse in the field. Our maintenance cost is lower because of this, not higher.
Subtraction is a feature.
Each release we ask which thing to remove. The answer is rarely 'nothing'. A narrow utility ages well; a broad one needs constant attention or it rots quietly under a settings menu.
Defaults are the product.
Most users never open a settings screen. The first-run path is the only path that scales. We treat it that way — most of our design time is spent on defaults, not options.
The handover is the point.
Every project we ship is built so a publishing partner could hand it off to another team in a year and recognise the codebase. Documentation is not a one-time output; it is what makes the work survive past us.
¶ next step