De una necesidad cotidiana a una app útil

Las mejores ideas de producto suelen empezar con una pregunta sencilla: ¿qué tarea cotidiana podríamos hacer un poco más clara? En nuestro caso, esa pregunta nos llevó a explorar cómo las personas organizan y entienden sus finanzas. No partimos de una lista de funciones. Partimos de un archivo que mucha gente ya tiene y casi nadie quiere leer entero: el extracto.

Empezar por el archivo

El recorrido que estamos probando es concreto. Una persona descarga o fotografía un extracto, en CSV, Excel, PDF o foto, y lo abre en Yavara. A partir de ese archivo, la app ordena movimientos y pone juntas las cuotas que se repiten, para que se puedan revisar sin recorrer fila por fila. El punto de partida es siempre el fichero que esa persona elige subir. No hay un paso anterior en el que pidamos usuario y contraseña del banco.

Eso también nos obliga a decidir qué no queremos pedir. Yavara no pide acceso a la cuenta. Tú subes el extracto y lo revisas dentro de la app. La privacidad entra en las primeras decisiones de producto, no como un texto que se añade al final.

Antes de dibujar pantallas, trabajamos en definir qué debería aportar una herramienta así: una lectura comprensible de la información, una experiencia que ayude a tomar decisiones y un espacio donde cada persona conserve el control de sus datos. Si el resultado no se entiende en una sentada, el archivo no ha servido de nada.

“Una app útil empieza por respetar el contexto y las decisiones de quien la usa.”

Una idea que guía el diseño de Yavara

Qué queda fuera

Pedimos el archivo y no el login del banco. Esa frontera explica el resto. No guardamos credenciales, no vemos la cuenta en directo y no actualizamos el extracto por nuestra cuenta. Si el mes siguiente quieres otra lectura, vuelves a elegir un archivo. Es más manual que una conexión permanente, y es la limitación que aceptamos para no pedir la cuenta.

Los datos que importas se guardan en una base cifrada en el dispositivo. El documento se procesa ahí cuando el teléfono tiene capacidad. Si hace falta usar nuestros servidores un momento, la app lo dice antes: no almacenamos esos datos ni los usamos para entrenar modelos. No describimos el proceso como algo que ocurre solo en el teléfono en todos los casos. El aviso existe precisamente porque hay un fallback temporal.

La prueba cerrada

La prueba de Android ya está abierta. Pedimos el correo de la cuenta de Google de ese teléfono y enviamos el enlace para instalarla. A quien entra le pedimos que mantenga la app instalada 14 días y que nos diga si el resultado le resulta útil. Si el banco es Revolut, ING, Santander, Sabadell o CaixaBank, se puede probar con un extracto propio: el archivo se queda en el teléfono. Quien solo tiene iPhone entra en la lista y le escribimos cuando abramos esa prueba.

Esos 14 días no son una métrica de éxito que podamos publicar. Son la forma de comprobar si ordenar un extracto, sin conectar el banco, ahorra el trabajo que la persona ya hacía a mano. Si la respuesta es que no, el siguiente ciclo cambia la app, no el discurso.

Construir, probar y aprender

El trabajo continúa en ciclos pequeños: aclarar una necesidad, proponer una solución, observar si se entiende y ajustar. Así mantenemos la conversación cerca del problema real y evitamos añadir complejidad porque sí. Cada ciclo tiene que poder explicarse con un archivo, una pantalla y una pregunta: ¿esto te ahorra la lectura a mano o solo la mueve de sitio?

Sobre Yavara

Yavara es el primer producto de Quiova Labs. Seguiremos compartiendo aquí las decisiones, dudas y aprendizajes que podamos explicar con honestidad mientras toma forma. El extracto sigue siendo el inicio. El login del banco sigue fuera. Y la prueba cerrada sigue pidiendo catorce días de uso real antes de que decidamos qué ampliar.