In the beginning, LowFlow was HTML.
And for a good while, that was enough. I built my journal, added my own functions, tested my ideas, and evolved the interface around my own needs.
Then the project changed direction. At some point, I decided LowFlow wouldn't stay just my personal tool. I wanted to make it a product. I wanted to be able to distribute it. To sell it. To have it install properly on Windows.
And that's when the question of a desktop application became serious.
The choice: Electron or a hybrid app
I now had to take the HTML journal and give it a real desktop shell. Electron was an obvious option. But I didn't want to turn a lightweight journal into a much heavier application just to produce an executable.
I wanted to keep the spirit of the project: simple, fast, light, and as close to Windows as possible.
So I chose a hybrid app. The principle suited me much better: keep my web interface, but wrap it inside a much lighter native application. That choice would become an important part of LowFlow's identity.
Today, the core of the App runs around 6 MB. But reaching that simplicity wasn't as simple as expected.
The problem wasn't the application
The application itself stayed small. The real problem was everything that would pile up around it. Trades. Screenshots. Histories. The data needed for replay. Backups. And everything a trader can accumulate after months or years of use.
At first, I didn't even realize this management would become such a big problem. Then I started hitting the limits of what I could let live directly around the application. And that's when I spent almost a week looking for a solution simple enough not to make LowFlow unstable.
Keeping the App light
The solution ended up being to clearly separate the application from its data. LowFlow wasn't meant to become a warehouse. The App had to stay the engine and the interface. The trader's data had to live in its own locations.
So I built a logic of dedicated paths. Trades have their location. Photos have their location. Histories have their location. Data used for replay can be kept separately. Backups too.
This keeps the application light even when the trader accumulates a lot of data.
Paths are controlled from settings
I also didn't want to lock the client into a structure they don't understand. Paths can be managed directly from LowFlow's settings. The trader knows where their data lives. And they can organize their storage according to their own setup.
That mattered to me. The software organizes. But the data stays with the client. Trader chooses.
The data belongs to the trader
This architecture also lets the client make their own backups. They don't need to depend on a LowFlow server to keep their history. They can create their own copies. LowFlow can also generate dated ZIP archives, which allows keeping several backups over time.
A journal can hold months or years of work. I wanted the client to be able to keep that history independently of the application itself.
Then the addons increased the volume
LowFlow's addons don't just pull in a single trade line. They can capture trades and their exits, screenshots taken during trading, and the historical data that will later let the client run their own replay.
That represents far more information than a simple transaction CSV. And that's exactly why this local architecture was necessary. The application stays around a few megabytes. The data, on the other hand, can grow with the trader.
A week of work so that nothing happens
This is one of the funny realities of development. I spent almost a week solving local data management to get something that, today, seems almost mundane.
The client opens LowFlow. Their data is there. Their images are there. Their history is there. Replay can use their files. The application stays light. And it doesn't crash.
When everything works correctly, this architecture becomes almost invisible. But without it, the rest of the project couldn't have kept growing properly.
And selling an application creates a new problem
Moving from HTML to an App had turned LowFlow into a real Windows application. But wanting to distribute and sell it now brought up other questions.
How do you manage clients? How do you manage licenses? How do you activate an installation? How do you know which version is being used? How do you send updates? And how do you avoid leaving all that logic solely on the client's machine?
At that point, keeping LowFlow purely local wasn't enough anymore. A new layer had to be built. The server and the API.