Vol. I — Chapter 02 — about
About the studio.
What follows is the studio in long form. The categories we ship in. How an engagement runs. The lines we hold to. The work we will refuse.
§ 01 — what this studio is
A small mobile
studio for narrow utilities.
With Scale is a small mobile utility studio. The work we do is unglamorous on purpose: we ship native iOS and Android utility apps in a fixed list of categories, on a written cadence, with publishing partners who want a small, well-built thing rather than a big, half-built one. Each app we ship is a co-creation — the partner handles distribution and the commercial side; we handle the design, the engineering, and the long-tail care.
We are deliberately small ourselves. Four people, distributed, mostly working in writing. We take on a small number of engagements at a time on purpose — the practice is most useful at sustained, weekly cadence over a quarter, and we cannot do that for more than a handful of titles at once without becoming a different kind of firm.
The publishing partners we are useful to share a few traits. They have already shipped a category once, or are confident in one they want to occupy. They want a small, narrow first version, not a flagship. They prefer written cadence to standups, and they understand that the second release is where the work gets interesting.
§ 02 — what we build
Six categories
we ship in.
A fixed list. We say no to anything outside it.
- I.
Cleaners
Photo and storage cleaners that do one kind of cleanup per release. We refuse to round up a number, refuse to run a fake sweep on an empty cache, refuse to inflate gigabytes that did not exist. The user gets the truth and decides what to delete.
- II.
Scanners
On-device document scanning that returns a clean PDF and walks away. No subscription nudge to keep the scans the user just made. No cloud-stored archive opt-in. The file leaves with the user.
- III.
VPN
Lightweight tunnel apps that disappear from the user's mind ten seconds after first launch. One toggle, one indicator, no dashboards. Predictable behaviour, honest about what they are and aren't.
- IV.
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.
- V.
File managers
Apps that keep the small filesystem on a phone honest. Sort, archive, prune, undo. No hidden hosted sync, no quiet upload to a backend the user did not opt into. The original copy stays the original.
- VI.
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.
§ 03 — how we work
Three short
stages, in order.
Listen, sketch, ship. Each stage finishes the previous one before the next one begins.
- I.
Listen
We start every engagement with 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.
- 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 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.
§ 04 — working principles
Four lines we
try to hold to.
N° 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. Our maintenance cost is lower because of this, not higher.
N° 02
Defaults are the product.
Most users never open a settings screen. The first-run path is the only path that scales at large numbers. Most of our design time is spent on defaults; options are a distant second.
N° 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 needs constant attention or it rots quietly under a settings menu.
N° 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 not a one-time output — it is what makes the work survive past us.
§ 05 — what we don't do
Four things we refuse.
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.
Refusal 01
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. We optimise for retention five quarters out, not the spike on the dashboard tomorrow.
Refusal 02
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.
Refusal 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.
Refusal 04
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.
¶ end of vol. I
If something on this page sounds like the kind of conversation you would like to have, we are reachable.