One person per app: how we structure ownership in a small studio

Most studios grow by specialising: a designer, two engineers, a marketer, a product manager, per team. We did the opposite. Each of our apps has one person who holds all of it, and the shape of the studio follows from that choice.

What one owner means

The person who designed the onboarding is the person who wrote the code, wrote the store page, set up the Apple Search Ads campaign and read this morning's reviews. When a review says the sleep timer ends too abruptly, the person reading it is the person who can fix it by the afternoon. There is no ticket, no handover and no meeting about priorities.

Why it works at our size

• Coherence. A product made by one mind feels like one product. Seams between specialists show.
• Speed. Decisions take minutes. Most of what slows a team is the cost of agreeing.
• Accountability. There is no ambiguity about whose app it is. Pride does the rest.

What it demands

A person who can design well enough, build well enough, write well enough and read a dashboard, and who wants all of it. That is rare, and it is who we hire for. It also demands humility: the owner is the first to notice when the app needs a skill they do not have, and asks for it.

Shared plumbing, separate products

The owner does not build everything from scratch. The story engine, voice, subscriptions, analytics and the loyalty layer are shared, maintained for all the apps. The owner builds the product on top. The backbone is common; the thing people download is personal.

Where it stops

When an app grows past what one person can hold in their head: too many markets, too many features, too many customers. At that point the app gets a second person, and the first one's job becomes keeping the whole still coherent. We have not reached it yet. We expect to, and we would rather hit that limit than build a hierarchy before the apps need one.