A studio's real constraint is not engineering capacity. It is attention. Every product added to the register is a product that must be supported, updated for each OS release, and answered for in the store reviews, forever. So the filter for what gets in matters more than the filter for what gets built well.

Four questions, in order. A concept has to pass all four.

1. Is the problem acute, and does it have a deadline?

Vague problems produce vague products. We look for a moment where a specific person is stuck, knows they are stuck, and has a date attached.

A bride with a boutique appointment on Saturday has a deadline. A player whose drive keeps fading and who is playing a round on Sunday has a deadline. Compare that to a general fitness tracker, where the user has an aspiration and no deadline at all. Aspirations churn. Deadlines convert.

2. Is there a visible artifact?

The product has to produce something the user can look at and immediately judge as right or wrong. The pose overlay traced onto their own throw. Themselves in sixteen dresses. Not a report, not a score, not a dashboard of derived metrics: a thing on the screen that the user can evaluate without trusting us.

This is a commercial filter disguised as a design one. A visible artifact is what someone screenshots and sends to a friend, and that is a distribution channel that does not have a cost per install.

3. Would this person pay, and do they already?

The useful version of this question is never "would users pay for this." It is "what are they paying for the bad version right now."

A disc golfer at a certain level already buys discs they do not need and considers lessons they never book. Someone planning a wedding is already spending in a category where a small fee to arrive at an appointment prepared is not the biggest line item that week. If nobody is spending anything in the adjacent space, we are not going to be the first.

4. Do we already own most of the machinery?

This is the studio-specific question and it is the one that gets applied last, deliberately. Building only what your existing infrastructure permits is how a portfolio ends up as five versions of the same app.

But it does break ties. Given two concepts that pass the first three tests, we take the one where the video pipeline, the billing rails, and the release process already exist. That is not a lack of ambition, it is the entire reason for the studio structure to exist.

What fails the filter

  • Anything whose value proposition is that it is powered by a model. That is an implementation detail, not a reason to open an app.
  • Products where the output is unfalsifiable. If the user cannot tell whether we got it right, they also cannot tell whether we got it wrong, which means they will never trust it enough to pay twice.
  • Concepts that need a network to be useful on day one. A studio cannot subsidize an empty marketplace across three other products.
  • Anything requiring a support burden we cannot honor. Two of us answering support for six apps is a promise we would break.
The hardest discipline in a studio is not building the next thing. It is declining to.