La respuesta corta
Conviene cuando el problema aparece con frecuencia, el resultado puede comprobarse y la tarea vale por sí sola. Si nadie vuelve y tampoco existe una forma razonable de encontrar usuarios, probablemente sea una función dentro de otro producto.
El problema debe caber en una frase
Open Eyes nació alrededor de una promesa que no necesita demostración comercial: abrir los ojos de alguien que parpadeó en una fotografía. La persona reconoce el problema, entiende el resultado esperado y puede comparar el antes y el después.
Esa claridad simplifica el producto. La persona elige una foto, genera el resultado y lo guarda. Cualquier pantalla que estorbe en ese recorrido tiene que justificar su lugar.
La superficie debe coincidir con la intención
Quien llega desde Google quiere arreglar una foto ahora. Por eso mantenemos una guía directa, con ejemplos, límites y acceso al editor web. Quien instala una app de iOS puede valorar una experiencia recurrente, controles adicionales y un lugar permanente en el teléfono.
No intentamos convertir la página de búsqueda en una presentación para empresas. Conserva su URL y responde primero a la fotografía. La historia de producto vive aquí, en una pieza separada para quien sí necesita esa decisión.
Una promesa estrecha también puede crecer
Con el tiempo, la edición web de ojos cerrados pasó a convivir con restauración, mejora de calidad y otras herramientas en Enhance.cam. Agrupar capacidades adyacentes hace más eficiente la operación web, mientras Open Eyes puede conservar una entrada reconocible y enfocada.
Open Eyes terminó siendo una entrada a un sistema más amplio. Eso funcionó porque la herramienta seguía explicándose sola, incluso después de compartir tecnología con otros productos.
La demanda decide qué se comparte
Antes de extraer una plataforma interna, buscamos dos usos reales. La generación y edición de imágenes puede compartirse entre Open Eyes, Enhance.cam y otros productos; la adquisición y el mensaje permanecen específicos para cada audiencia.
Esto evita construir infraestructura abstracta demasiado pronto. Primero resolvemos el problema completo. Después reutilizamos las partes que ya demostraron valor.
Criterio de decisión
Antes de hacer una app, buscamos esto
No es una fórmula. Son preguntas que ahorran bastante código innecesario.
- 01
La persona puede describir el problema y reconocer un buen resultado.
- 02
La tarea aparece con suficiente frecuencia o tiene suficiente valor por ocasión.
- 03
Existe un canal de adquisición que coincide con esa intención.
- 04
La calidad, el tiempo de respuesta y el coste por generación pueden sostener el precio.
- 05
Resolver la tarea bien exige controles, estados o recorridos propios.
El límite
No toda función merece su propia app
Si la persona usa la función una vez y desaparece, quizá deba vivir dentro de un producto más amplio. Separarla solo añade otra cuenta, otra interfaz y otro producto que mantener.