Issue 01 — A small mobile studio
Slow.
ROLO is a tiny mobile studio that ships small utility apps — the kind you reach for once a week, never think about, and never delete.
We work in narrow categories on iOS and Android. We ship slowly on purpose. We charge fairly, write our own copy, and reply to email.
Read the categories →Chapter 01
How we work.
Three short cycles, each finishing the one before. We don't move on until the previous step has stopped surprising us.
- I.
Listen
We start every engagement on a written brief and one long, uninterrupted conversation. We are trying to understand what the work is — not what it could be made to sound like in a deck.
- II.
Sketch
A short, deliberate prototype loop. Usually a week. We decide what stays and, more importantly, what gets cut. Most things get cut.
- 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 delighted by version four.
Chapter 02 — Working principles
A few things
we've learned
to hold to.
We are distributed and asynchronous on purpose. Most of what is hard about running a small studio across timezones — coordination, status updates, the slow accumulation of context — gets easier when written down. So we write it down. Meetings are the exception in our calendar, not the rule.
The team is small enough that everyone touches the work end to end — research, design, code, release, answering email when something breaks at midnight. There is no separate “production” layer between someone caring about a problem and the user feeling the result.
Most of what we build is intentionally narrow. A cleaner that does one kind of cleanup well. A scanner that doesn't pretend to be a converter. A converter that doesn't pretend to be a cloud platform. We'd rather ship a handful of small things that work than a single thing that tries to be all of them — and we'd rather close the laptop at five than launch a feature we wouldn't use.
“The default behaviour of an app is the only behaviour that matters at scale. We spend more time on defaults than on options.”
We've also learned to be honest about the parts we don't do. Our pricing is straightforward, our scope is narrow, our timelines are written down before they're agreed to. The work is small. The intention is to keep it that way.
Chapter 03
What we don't do.
The shape of a studio is mostly what it refuses. These are ours.
We don't disguise small numbers.
No theatrical animations on a sweep that found nothing. No fake progress bars. The number on the screen is the number we measured.
We don't take on every category.
We work on a narrow set of utility categories on iOS and Android. The scope of what we know how to ship well is the scope of what we ship.
We don't run growth loops that confuse the user.
If a feature only converts when the user misunderstands it, we don't ship it. The first onboarding screen earns the second one.
We don't promise outcomes.
We aim to. We design to. We build so that. We stop short of guaranteeing what only the user gets to feel.
¶ end of issue 01
If any of this sounds like the kind of thing you'd like a studio to do for you, we're reachable.