A month after launch
The studio site went live a month ago. Not the apps — most of those have been shipping for a while — but the studio itself, with a name attached and a public-facing voice. A month is not enough time to learn much, but it’s enough to notice a few things.
Before the site existed, each app was its own island. People knew KeyRush or Fisharo or Resukai, but there was nowhere that explained who made them or how. Putting a single name over all of that work was a small change on paper and a bigger one in practice.
What changed
The amount of inbound email grew noticeably. Most of it is thoughtful: support questions, feature requests with real context, the occasional kind note. A surprising number are from other small developers asking us how we structure the team. We’re going to write about that more, gradually, in this journal.
The support email changed shape, too. When people only knew a single app, they wrote about that app. Now some of them write about several at once — a resume builder and a typing trainer during a job hunt, say, or a habit tracker on the phone and its blocker extension in the browser — and they want to know how those fit together. That’s a useful signal: people see the apps as a family, even though each one was built to stand on its own.
We also noticed how much a public page raises the bar for consistency. Store listings, support replies and app descriptions written at different times suddenly sit side by side. We’ve spent part of the month tidying that up — same tone, same facts, no contradictions between platforms.
What didn’t
The work itself. The cadence we ship on, the way we review designs, the things we choose to add and the things we refuse. Having a public studio page doesn’t change how the apps get built — it just gives the people who use them a place to read about that work.
That was deliberate. There’s a temptation, once you have an audience, to start building for the audience — shipping things because they’ll make a good announcement rather than a better app. We’d like to avoid that. The journal follows the work, not the other way round.
What we’d do differently
We underestimated how long it takes to answer email well. A good reply to a thoughtful message takes real time, and in the first weeks our replies slipped further behind than we’d like. We’ve since set aside regular time for it, instead of squeezing replies in between other work.
We’d also have written a few journal posts before launch rather than after. The questions we got in the first weeks were predictable in hindsight — how we price, how we pick what to build, why we stay small — and having answers ready would have saved some long individual replies.
What’s next
More of the same, carefully. More apps on more platforms where it makes sense, more posts here when there’s something real to say, and steady improvements to what’s already shipped.
Thanks to everyone who reached out in the last few weeks. We’re reading every email, even when the reply takes a few days.