ABOUT.
What kind of studio this isFour people, six categories, one inbox.
Distributed, asynchronous, weekday inbox.
Plain talk about the studio.
Tempus Fugit is a small mobile studio that ships utility apps in a fixed list of six categories. Every release is a co-creation with a publishing partner. The studio handles the design, the engineering, and the long-tail care of each title; the partner handles the distribution and the commercial side. It is not the only way to build apps, but it is the way that has kept us in the work for several years now without burning out.
We are deliberately small. Four people, mostly working from where they live, mostly working in writing. The studio runs on a calendar that we can keep — and on a list of categories that, by now, we know how to ship cleanly. Both lists are short on purpose. The discipline is mostly in the saying-no.
We try to be honest about what a small studio can and cannot do. We are a good fit for a partner who has a category and a willingness to ship a narrow first version. We are a poor fit for a partner whose plan starts with three product lines and a press tour.
“The shape of a studio is mostly what it refuses. Ours refuses a lot, on purpose.”
Four people, by role.
We do not list names or photos here. Introductions happen by email, after the first conversation, where they belong. What follows is what each person spends their day doing.
Role
Engineer
Closes the IDE before the laptop. Treats failed tests as a chance to learn what the spec actually was, not a chance to argue with the test. Has a keyboard shortcut for everything and is annoyed when you don't.
Role
Designer
Spends more time on default states than on hero states. Keeps a separate sketchbook for ideas they decided not to ship. Will redraw the empty state of a feature three times before the populated state once.
Role
Producer
Owns the calendar that says when you'll know. Won't promise the day. Will promise the week, and will revise it out loud the moment that becomes inaccurate.
Role
Researcher
Asks about Tuesdays at three in the afternoon, not about ideal users. Reads the second page of the support tickets. Brings back the question you didn't know you were avoiding.
Four lines we try to live by.
Pick the work you can finish.
We say no a lot. The studio runs on a calendar we can actually keep, and on a list of categories we know how to ship. Both lists are deliberately short. The discipline is mostly in the saying-no.
Pricing is plain.
There is a number, the work it covers, and what it does not. The number does not change once we have shaken on it. We do not unbundle it after the fact and charge again under a different name.
Onboarding is an explanation, not a moat.
The first time someone opens a thing we shipped, they should leave knowing how the thing works. They should not leave having tapped through a forest of upsell screens. The friction we add to onboarding is how we lose the next year of trust.
We write copy first, then code.
If we cannot describe what an app does in two sentences before the build starts, the build starts on the wrong day. Every project here begins as a one-page brief. The brief stays close to hand all the way through.
Services →
The six categories, described the way we'd describe them on a first call. The five questions we get most often. The email address.