The short answer
It makes sense when the problem comes up often, the result is easy to judge, and the task is valuable on its own. If nobody returns and there is no sensible way to find users, it probably belongs inside another product.
The problem should fit in one sentence
Open Eyes began with a promise that needs very little explanation: open the eyes of someone who blinked in a photograph. A person recognizes the problem, understands the expected result, and can compare the before and after.
That clarity simplifies the product. A person chooses a photo, generates the result, and saves it. Any screen that gets in the way has to earn its place.
The surface should match the intent
Someone arriving from Google wants to fix a photo now. That is why we keep a direct guide with examples, limitations, and access to the web editor. Someone who installs an iOS app may value a repeatable experience, more controls, and a permanent place on their phone.
We do not turn the search page into a pitch for companies. It keeps its URL and answers the photo question first. The product story lives here, in a separate piece for the reader making that decision.
A narrow promise can still grow
Over time, closed-eye editing on the web came to sit alongside restoration, quality enhancement, and other tools inside Enhance.cam. Grouping adjacent capabilities makes the web operation more efficient, while Open Eyes can preserve a focused and recognizable entry point.
Open Eyes became an entrance to a broader system. It worked because the tool still made sense on its own, even after it began sharing technology with other products.
Demand decides what becomes shared
Before extracting an internal platform, we look for two real uses. Image generation and editing can be shared by Open Eyes, Enhance.cam, and other products; acquisition and messaging remain specific to each audience.
This keeps us from building abstract infrastructure too early. We solve the complete problem first, then reuse the pieces that have already demonstrated value.
Decision criteria
What we check before building an app
This is not a formula. These questions save a surprising amount of unnecessary code.
- 01
A person can describe the problem and recognize a good result.
- 02
The task occurs often enough or carries enough value per occasion.
- 03
There is an acquisition channel that matches the intent.
- 04
Quality, response time, and generation cost can sustain the price.
- 05
The experience needs more than an isolated button inside another product.
The limit
Not every feature deserves its own app
If someone uses the feature once and disappears, it may belong inside a broader product. Pulling it out only adds another account, another interface, and another product to maintain.