← Blog

Episodio 2

El prototipo: cuando el diario se convirtió en una herramienta real

Al principio, LowFlow todavía era simple.

Sobre todo había que lograr una cosa: convertir la idea del diario en algo lo suficientemente práctico como para usarlo de verdad. No una maqueta. No una demostración. Una herramienta donde se pudiera registrar un día de trading, volver sobre él y empezar a aprender de los propios datos.

El primer objetivo: dejar de perder el contexto

Una operación, tomada sola, casi no cuenta nada. Una entrada. Una salida. Una ganancia o una pérdida. Pero alrededor de esa operación hay mucho más. El plan antes de la sesión. La razón de la entrada. El setup. El estado de ánimo. La calidad de la ejecución. La captura del gráfico. Las notas tomadas después de la operación. Y a veces, varios días después, el trader quiere entender por qué esa decisión parecía buena en ese momento.

El prototipo entonces empezó a acumular esas piezas. Operaciones. Notas. Planes. Estadísticas. Capturas. Análisis. Replay. Con cada nueva función, el diario se volvía un poco menos un simple registro y un poco más un entorno de trabajo.

El diario debía contar el día

Una de las ideas importantes era poder revisar una sesión como un conjunto. No solo una serie de transacciones. En LowFlow, el trader puede preparar su plan previo al mercado y luego encontrar ese plan directamente en su día de trading. Junto a él, ve después lo que realmente ocurrió: su P&L, su win rate, su profit factor, su expectancy, su drawdown, sus operaciones, sus setups, sus notas.

El plan entonces no desaparece una vez que abre el mercado. Se mantiene ligado al día. El trader puede comparar lo que había previsto con lo que realmente ejecutó. Ahí es donde el diario empieza a ser útil.

Las capturas se convierten en parte del análisis

Las imágenes rápidamente ocuparon un lugar importante. El trader puede soltar una captura por drag and drop o importarla directamente en el diario. Pero no quería que quedara como un simple archivo adjunto. Después puede modificarla, agregar texto, marcar lo que estaba observando, documentar una entrada o una salida, y conservar esa imagen junto con el resto del contexto de la operación.

Una captura se convierte entonces en parte de la memoria de la operación. Semanas después, no ve solo un resultado. Puede volver a ver lo que realmente estaba viendo en el mercado.

Las estadísticas, pero nunca impuestas

Surgió otra decisión muy temprano. Muchos sistemas calculan todo sobre el conjunto de las cuentas. Yo no quería eso. El trader debía poder decidir qué cuentas entraban en sus cálculos.

El panel izquierdo entonces se volvió mucho más que un menú. Controla el contexto activo del diario. El trader selecciona las cuentas que quiere analizar y las estadísticas se construyen alrededor de esa selección. Si solo quiere mirar dos cuentas funded, puede. Si quiere comparar un grupo específico, puede. Si quiere incluirlo todo, también puede.

Una vez más: El Trader Elige.

Un poco de personalidad también

No quería construir únicamente tablas grises llenas de números. El diario debía tener una identidad. Ahí es donde empezaron a aparecer los pequeños detalles visuales: las estadísticas que se deslizan, las vistas más gráficas, los paneles que pueden desaparecer para liberar espacio y el modo privado con su pantalla animada.

No son las funciones más importantes técnicamente. Pero contribuyen a algo esencial: dar ganas de usar el diario. Una herramienta que se usa todos los días debe ser agradable de abrir.

Luego el prototipo empezó a ponerse demasiado serio

Probablemente ese fue el momento en que el proyecto cambió de naturaleza. Al principio, agregar una función simplemente significaba modificar el diario. Después las funciones empezaron a depender unas de otras. Las capturas ocupaban espacio. Los datos se acumulaban. El replay exigía cada vez más historial. Las cuentas debían organizarse. Los ajustes empezaban a importar. Y el diario debía conservar todo esto sin volverse pesado o inestable.

El prototipo funcionaba. Pero empezaba a superar lo que un simple proyecto HTML podía manejar cómodamente. Ahora había que darle una verdadera estructura de aplicación. Ahí fue cuando Tauri entró en la historia.

Y ahí también fue cuando descubrí que un software ligero puede volverse muy pesado muy rápido si no se decide correctamente dónde viven sus datos. Esa parte me costó mucho más tiempo del previsto. Será el tema del próximo episodio.

← Volver al blog