Volver a la bitácora
30 de abril de 20266 min de lectura

VantFi en sprint 3: lo que cambiamos del MVP después de probar con 10 personas

Diez personas reales usaron el primer prototipo de VantFi durante una semana. Lo que aprendimos, lo que cortamos, lo que rediseñamos, y los tres bugs que nadie esperaba.

building-in-publicvantfiflutter

Llegué al final del sprint 2 con un VantFi que técnicamente funcionaba: registrabas ingresos, gastos, deudas, metas. El dashboard mostraba números. El backend respondía. Un éxito en cualquier checklist técnico. Después se lo di a 10 personas reales y descubrí que técnicamente funcionar y resolver el problema del usuario son cosas distintas.

El test, sin spoilers

Recluté 10 personas: 4 amigos cercanos, 3 conocidos de la oficina vieja, 3 familiares de distintas edades. Les instalé el TestFlight, les expliqué que el objetivo era "úsenlo durante una semana, registren lo que gastan, y avísenme cuando algo no tenga sentido". Sin guía adicional. Sin tutorial.

La mayoría logró registrar el primer gasto el primer día. La retención bajó significativamente entre el día 1 y el día 7, lo cual es normal para un MVP sin onboarding pulido. Lo importante no fueron los números — fueron las razones por las que la gente se caía. Ahí estuvo la mina de oro real.

Lección 1: el quick-add no era tan quick

El flujo era: tap en el botón flotante, formulario de gasto, escribe el monto, elige la categoría, elige la cuenta de origen, escribe una nota opcional, guarda. Yo lo veía como "5 campos, esto es rápido". Para 6 de las 10 personas, eso era demasiado.

Lo cambié así: tap en el botón flotante abre un teclado numérico full-screen, escribes el monto (es lo único obligatorio), tocas guardar. La categoría se infiere del último gasto similar; la cuenta es la default; la nota se omite. Si quieres editar algo después, abres el detalle y cambias. Pasamos de 5 campos a 1. La fricción del registro bajó al punto donde se siente como anotar en una nota — que era exactamente la metáfora correcta.

Lección 2: las categorías default eran del primer mundo

Mi lista inicial eran las categorías genéricas de cualquier app de finanzas gringa traducidas al español: "Comida, Transporte, Entretenimiento, Salud, Servicios, Otros". Los testers prácticamente no las usaron. Cada quien me pedía categorías que coincidían con cómo realmente gastan plata aquí — términos del día a día colombiano que no existen en una taxonomía importada.

Reescribimos las categorías default desde cero a partir de esas sugerencias. Esta es de las decisiones donde el customer development gana de lejos contra cualquier benchmark de competencia: las palabras correctas no se diseñan en una pizarra, se escuchan.

Lección 3: el dashboard era abrumador

Mi dashboard mostraba: balance del mes, gráfico donut por categoría, lista de últimos movimientos, indicadores de progreso de metas, total de deudas, ingresos pendientes. Todo en una pantalla. Para mí, ingeniero, esa densidad era información útil. Para el usuario que abre la app durante 30 segundos en el bus, era ruido.

Lo simplificamos a tres tarjetas grandes: "Cuánto gastaste hoy", "Cuánto te queda este mes", y "Tu próxima cuota grande". Todo lo demás se mueve a pantallas separadas accesibles desde el menú. La métrica que mide si esta versión funciona: cuánto tiempo tarda un usuario en entender en qué quedó su mes con un solo vistazo. Antes: ~8 segundos de leer y procesar. Ahora: ~2.

Tres bugs que nadie esperaba

Bug 1: si el usuario cambia el idioma del teléfono a inglés mientras la app está abierta, los meses se mostraban en la mezcla de los dos. Causa: cache de DateFormat sin invalidar al cambiar locale. Fix: invalidar al recibir el evento del sistema.

Bug 2: registrar un gasto a las 23:59 lo agrupaba en el mes siguiente porque el server estaba en UTC. Causa: estaba almacenando el timestamp y agrupando server-side sin offset. Fix: el offset del usuario va con cada registro, el agrupamiento respeta su huso.

Bug 3: dos personas tenían más de 200 transacciones para importar de un export de su banco. La app no las cargaba. Causa: límite tonto en el endpoint de import. Fix: paginación + progress bar visible.

Lo que sigue

Sprint 4 va a abrir la lista de espera pública. El producto no está listo para todo el mundo, pero está listo para 50-100 personas más, que es lo que buscaré. El criterio de "listo para producción" sigue siendo: yo lo uso todos los días sin frustrarme. Aún no llegamos, pero está mucho más cerca después de este sprint.