◆ A small mobile utility studio
Ship small.
Hold to it.
Vol. I · Fieldnotes from a small mobile studio · May 2026
We ship native iOS and Android utility apps in six fixed categories — quietly, on a written cadence, with publishing partners who want a small, well-built thing rather than a big, half-built one.
What follows is the practice in long form: the six categories we work in, the three-stage shape of an engagement, the four lines we hold to, and the four things we refuse. There is no contact form on this site — only an email address, which we read by the next working day.
Six categories we ship in.
Six fixed categories. We work in these and only these — taking on a category we have not shipped well in is, in our experience, how a small studio quietly ships a worse version of something already crowded.
§ 01.01
Cleaners.
Photo and storage cleaners that do one kind of cleanup per release. We refuse to round up the number, refuse to inflate gigabytes that did not exist, refuse to run a fake sweep on an empty cache. The user gets the truth and decides what to delete.
§ 01.02
VPN.
Lightweight tunnel apps designed to be forgotten once turned on. Connect, stay connected, never need a settings excursion. There are no dashboards because nothing on a dashboard would still be true ten minutes from now. One toggle, one indicator, the rest is invisible.
§ 01.03
Scanners.
On-device document scanning that returns a clean PDF and walks away. No nudge to subscribe in order to keep the scans the user just made. No cloud-stored archive opt-in. The file leaves with the user.
§ 01.04
Converters.
Files in, files out. Image, audio, document. We do not delete the source to look efficient, we do not enrol the user in a subscription to keep their own outputs. The original copy stays the original until the user explicitly says otherwise.
§ 01.05
Privacy utilities.
Apps designed to minimise the data they touch. Local-first when we can be; transparent about every off-device call when we cannot. We are careful never to claim guarantees we cannot defend in writing.
§ 01.06
Battery & device.
Diagnostic-style apps that surface what the device is actually doing. We refuse to ship a 'boost' button — phones do not get faster from a button, and shipping one would be a small lie compounding across the years a user keeps the app installed.
Listen. Sketch. Ship.
Three stages, in order. Each finishes the previous one before the next one begins.
§ 02.01
Listen
We start every engagement on a written brief from the publishing partner 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.
§ 02.02
Sketch
A short, deliberate prototype loop — usually a week. We decide what stays and what gets cut. Most things get cut. The prototype is the artefact a partner can react to before any commitment is made.
§ 02.03
Ship
Submit, watch real usage, refine. The first release is the start of the work, not the end. 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.
Four lines we work by.
§ 03.01
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. Maintenance cost is lower because of this, not higher.
§ 03.02
Defaults are the product.
Most users never open a settings screen. The first-run path is the only path that scales. We spend more design time on defaults than on options.
§ 03.03
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 rots quietly under a settings menu.
§ 03.04
The handover is the point.
Every project is built so a publishing partner could hand it off to another team in a year and recognise the codebase. Documentation is what makes the work survive past us.
Four things we don't do.
The shape of a small studio is mostly what it refuses. These are ours — written plainly so a prospective partner can decide quickly whether we are the wrong shop.
§ 04.01
We do not ship 'boost' buttons.
Phones do not get faster from a button. We refuse the small handful of design tricks that compound across years into a worse user experience.
§ 04.02
We do not run growth loops that confuse the user.
If a feature only converts when the user misunderstands it, we will not ship it. The first onboarding screen earns the second one.
§ 04.03
We do not take on every category.
We work on a fixed list of utility categories and we say no to the rest in writing. Taking on a category we have not shipped well in is, in our experience, how a small studio quietly ships poorly.
§ 04.04
We do not promise outcomes.
We aim to. We design to. We build so that. We stop short of guaranteeing what only the user gets to feel.
Email is the channel.
We watch the inbox during the working day and reply by the next one. If your project has a real deadline, put a date in the subject line and we will prioritise honestly.
o_lindberg_performance@adminlabs.proA useful first email is one or two paragraphs. Tell us what you are hoping to ship, which one or two of the categories it most closely fits, and roughly when you would like to begin. Specifics help; polish is unnecessary.