Scan Packs en Enolisa: monetizar una feature con coste variable sin perder confianza
Una reflexión técnico-producto sobre cómo convertí el escaneo de etiquetas de vino en una línea monetizable, equilibrando coste variable, experiencia de usuario, negocio, arquitectura y QA.
Una feature no vive aislada
El escaneo de etiquetas de vino en Enolisa es una funcionalidad muy natural para el usuario. Si estás registrando un vino, tiene sentido apuntar con la cámara y avanzar más rápido que rellenando todos los datos a mano.
Pero desde el lado del producto hay una diferencia importante: no todas las funcionalidades tienen el mismo coste de operación. Una pantalla, un filtro o una mejora local pueden tener mucho coste de construcción inicial, pero no necesariamente generan coste cada vez que se usan. El escaneo sí.
Cada uso implica procesamiento, backend, interpretación del resultado, posibles errores recuperables y una expectativa clara por parte del usuario: si la app promete ayudar, debe entregar valor. Por eso no bastaba con pensar “añadimos escaneo” y ya está. Había que decidir cómo se sostenía esa capacidad dentro del modelo de negocio.
Este artículo no pretende documentar la implementación interna de Enolisa. Lo relevante no es enseñar cómo está hecho cada detalle, sino explicar el tipo de decisiones que hay detrás cuando una funcionalidad atractiva también tiene coste variable. Ahí es donde se ve realmente el trabajo: convertir una oportunidad de producto en una capacidad operativa, medible y razonable para el usuario.
La pregunta de negocio
La pregunta inicial era sencilla de formular y difícil de resolver bien:
¿Cómo permito que el usuario pruebe una funcionalidad valiosa sin tratar su coste como si fuera gratuito?
Si se bloquea demasiado pronto, la feature pierde capacidad de adquisición y descubrimiento. Si se regala sin límites, el producto absorbe un coste variable sin una relación clara con ingresos. Si se empuja todo hacia Premium, algunos usuarios con necesidades puntuales quedan fuera. Y si se cobra por cualquier intento fallido, la confianza se rompe.
El reto no era solo monetizar. Era hacerlo sin deteriorar la experiencia.
Mi trabajo en este punto fue ordenar la decisión en tres planos:
- negocio: qué comportamiento de usuario queremos permitir y qué comportamiento debe tener una vía de pago;
- producto: cómo explicar el límite sin convertirlo en castigo;
- tecnología: qué garantías mínimas necesita el sistema para no generar inconsistencias.
Cuando esas tres capas se diseñan por separado, aparecen grietas. Cuando se diseñan juntas, una feature deja de ser una pantalla y se convierte en una pieza de producto.
La decisión: probar, comprar puntualmente o usar intensivamente
La solución fue separar tres intenciones de usuario:
- quien quiere probar el escaneo de forma limitada;
- quien necesita más usos puntuales sin comprometerse a una suscripción;
- quien quiere uso intensivo dentro de una experiencia Premium.
Esa separación es más importante de lo que parece. No todos los usuarios están en el mismo momento. Un usuario puede estar evaluando la app, otro puede estar registrando varias botellas concretas y otro puede usar Enolisa de forma recurrente. Forzar a todos a pasar por la misma puerta suele ser mala señal de producto.
Los Scan Packs nacen para cubrir esa zona intermedia. No sustituyen a Premium y no convierten el primer contacto en una compra obligatoria. Son una respuesta a un caso de uso concreto: necesito más capacidad ahora, pero no necesariamente quiero cambiar mi relación completa con el producto.
Esto también ayuda a explicar mejor el valor. La monetización no aparece como un bloqueo improvisado, sino como una extensión lógica de una funcionalidad que tiene coste real.
Donde está el valor técnico
La parte visible puede parecer simple: el usuario llega a un límite, entiende sus opciones y decide si compra más capacidad o pasa a Premium.
La parte importante está detrás. No por los nombres concretos de los servicios, sino por las garantías que había que preservar:
- el usuario no debe perder confianza por un fallo técnico;
- la app no debe conceder derechos de uso basándose solo en una suposición local;
- una compra no debe procesarse dos veces;
- una cancelación o un error deben tratarse como estados normales, no como casos raros;
- la medición del embudo no debe gobernar el derecho de uso;
- el sistema debe poder evolucionar sin mezclar reglas de negocio, interfaz y validación.
Ese es el tipo de arquitectura que me interesa construir. No arquitectura como diagrama bonito, sino como reparto claro de responsabilidades. La app coordina la experiencia. El backend protege las decisiones sensibles. El estado de cuenta debe ser consistente. La analítica observa. El QA valida los escenarios que afectan a confianza y dinero.
Contado así, no hace falta publicar rutas internas, contratos, nombres de funciones, campos concretos ni reglas operativas. La credibilidad no está en enseñar el plano completo. Está en demostrar que se entienden las fronteras.
La regla de producto: cobrar por valor, no por ruido
Una de las decisiones más importantes fue tratar el consumo de escaneos desde la perspectiva del valor entregado.
Si el usuario intenta escanear una etiqueta y el sistema no consigue devolver un resultado suficientemente útil, no tiene sentido que perciba que ha “gastado” algo. Aunque haya habido coste técnico, la experiencia de producto debe distinguir entre intento y valor.
Esta regla parece sencilla, pero obliga a diseñar bien el flujo. Primero hay que saber si el usuario puede iniciar la acción. Después hay que decidir si realmente se ha entregado algo que justifique consumir capacidad.
Esa diferencia cambia la percepción. Un límite puede ser razonable si se entiende y se aplica con justicia. Un límite puede parecer abusivo si se activa en el momento equivocado.
Este tipo de matices son los que separan una monetización pegada al final de una monetización integrada en el producto.
De idea a especificación
Antes de implementar, la parte crítica fue convertir la intuición en una especificación de trabajo.
No era suficiente escribir “añadir packs de escaneo”. Había que responder preguntas más incómodas:
- qué problema de negocio resuelve;
- qué usuario lo necesita;
- dónde aparece dentro del flujo natural de la app;
- qué estados debe entender la interfaz;
- qué pasa con errores, cancelaciones o reintentos;
- qué debe medirse;
- qué no puede depender nunca de la analítica;
- cómo se valida que la experiencia es coherente;
- qué información conviene documentar y qué información no debe salir del ámbito interno.
Aquí es donde la IA me aporta mucho valor. La uso para acelerar análisis, tensionar casos límite, revisar responsabilidades, transformar decisiones en specs y mantener documentación viva. Pero la IA no sustituye el criterio. La decisión de negocio, el nivel de exposición pública, la prioridad de QA y el equilibrio entre conversión y confianza siguen siendo responsabilidad humana.
En Enolisa este patrón se repite bastante: una idea empieza como una hipótesis de producto, pasa por varias iteraciones de documento, se convierte en plan de implementación y después se valida contra comportamiento real. Ese proceso no es accesorio. Es parte del producto.
UX: explicar sin presionar
La monetización de una feature de uso frecuente tiene un riesgo claro: interrumpir al usuario justo cuando intenta hacer algo.
Por eso el diseño de la experiencia tenía que ser transparente. El usuario debe entender que existe una capacidad limitada, que hay alternativas y que Premium sigue siendo una relación distinta con el producto.
La intención no era esconder el límite ni maquillarlo. Era explicarlo con naturalidad:
- estás usando una funcionalidad con coste operativo;
- tienes una forma de probarla;
- si necesitas más, existen opciones;
- si tu uso es intensivo, Premium tiene sentido;
- si algo falla, la experiencia debe responder de forma clara.
Este enfoque me parece especialmente importante en productos pequeños. La confianza se construye con muchos detalles de este tipo. No basta con que la compra funcione técnicamente. Tiene que sentirse coherente dentro del producto.
Medir sin convertir la medición en autoridad
Un evolutivo así necesita medición. Sin datos, es difícil saber si el usuario entiende el límite, si los packs resuelven una necesidad real o si Premium sigue siendo la mejor opción para ciertos perfiles.
Pero hay una línea que no conviene cruzar: la analítica no debe ser la fuente de verdad de una compra ni de un derecho de uso.
La analítica debe ayudar a aprender:
- dónde aparece fricción;
- qué opción despierta más intención;
- qué mensajes generan abandono;
- qué comportamiento tiene el usuario después de comprar;
- cómo conviven packs y Premium.
Pero si una medición falla, el producto no debería fallar por eso. Esta separación es una señal de madurez técnica. Los datos ayudan a decidir. No deben sustituir a los sistemas que protegen la experiencia del usuario.
Qué dice esto de mi forma de trabajar
Para mí, Scan Packs es interesante porque junta varias capas en una sola decisión:
- modelo de negocio;
- diseño de producto;
- experiencia de usuario;
- arquitectura móvil y backend;
- compras in-app;
- analítica;
- documentación;
- QA;
- uso operativo de IA.
No es el tipo de trabajo que se entiende bien si solo se mira una pantalla. El valor está en conectar piezas.
Un perfil técnico-producto no debería limitarse a “hacer lo que pone el ticket”. Debe poder cuestionar el modelo, detectar riesgos, ordenar la implementación, proteger la confianza del usuario y convertir una idea comercial en una capacidad mantenible.
Ese es el posicionamiento que quiero construir con Enolisa y con este blog. No desde el discurso de “sé usar IA”, sino mostrando casos donde la IA forma parte de un método de trabajo más amplio: pensar mejor, especificar mejor, ejecutar más rápido y validar con más rigor.
Lo que no cuento
También es importante marcar límites.
No tiene sentido publicar la lógica interna completa de monetización, nombres de componentes, contratos exactos, reglas privadas, umbrales, estructura de datos, estados operativos o detalles que puedan ayudar a replicar o tensionar el sistema.
Un artículo técnico no tiene que ser una filtración de arquitectura. Puede aportar valor explicando decisiones, trade-offs y aprendizajes sin convertir el producto en documentación pública para terceros.
Ese equilibrio es delicado. Si el artículo cuenta demasiado poco, pierde credibilidad. Si cuenta demasiado, regala conocimiento que pertenece al producto. La línea correcta está en enseñar criterio, no en publicar el manual interno.
Aprendizajes transferibles
El primer aprendizaje es que una feature con coste variable no se monetiza al final. Se diseña desde el principio junto con experiencia, límites, confianza y operación.
El segundo es que no todos los usuarios tienen la misma intención. Una prueba gratuita, un pack puntual y una suscripción pueden convivir si cada uno responde a un momento distinto.
El tercero es que las compras necesitan garantías técnicas, pero no hace falta convertir esas garantías en documentación pública. Lo importante para el lector es entender el principio: consistencia, validación y protección frente a duplicidades.
El cuarto es que la IA aporta valor cuando ayuda a estructurar decisiones y no solo a escribir código. En este caso sirve para preparar specs, revisar escenarios y mantener un hilo entre negocio, producto y desarrollo.
Y el quinto es que el posicionamiento profesional no se construye diciendo que uno controla muchas áreas. Se construye mostrando cómo se conectan esas áreas en decisiones reales.
Para mí, Scan Packs es una pieza más de ese camino: Enolisa como producto real, pero también como forma de demostrar una manera de trabajar end-to-end.
Lecturas relacionadas
Este artículo forma parte de una línea de trabajo más amplia sobre cómo estoy construyendo Enolisa como producto técnico, desde IA y arquitectura hasta monetización y experiencia de usuario.
- Control de stock en Enolisa: convertir una vinoteca en inventario útil sin perder simplicidad
- El trabajo que viene: perfiles end-to-end, IA y adaptación profesional
- Cómo uso Codex como capa operativa de desarrollo en Enolisa
- De la idea a la spec: cómo convierto intuiciones de producto en planes de trabajo con IA
- Creando un modelo generativo propio con Genkit y arquitectura orquestada sobre Firebase