In the beginning, I wanted something simple.
A local application.
The trader installs LowFlow on their computer, their data stays with them, and the app does its job without needing to send their entire trading life somewhere in the cloud.
That was the philosophy from the start. And it still is today.
But as LowFlow kept moving forward, the project became more serious. And a problem I hadn't really thought about at the beginning eventually showed up.
How do you turn a local application into a real commercial product?
I wanted to stay local
I had no interest in turning LowFlow into a SaaS.
I didn't want a client's trades to be sent to my servers just for their journal to work. I didn't want their photos, their history, or the data needed for replay to depend on a cloud either.
The principle was simple: the trader keeps their data. Their trades stay on their machine. Their screenshots stay on their machine. Their history stays on their machine. Their replay data stays on their machine. Even their backups can stay under their own control.
That was an important decision. And I didn't want to change it just because LowFlow was becoming commercial.
But the project had changed
The problem came from somewhere else.
An application I build for myself can work a certain way. An application I want to distribute to clients has to handle a lot more.
You need to be able to identify an installation. Manage licenses. Know which version of the software is being used. Allow updates. Manage accounts. Control access. Distribute new versions.
And above all, I wanted to be able to do all of that without turning LowFlow into an application that depends entirely on a server.
That's when I started to understand I needed another layer. Not for the trader's data. For everything around the application.
The application stays with the trader
This is probably the most important part to understand.
LowFlow is installed locally. The application is on the trader's computer. Their data is local. But the application now needs to be able to communicate with my infrastructure for certain functions.
It's a bit like a cell phone. The phone is in your hand. Your apps are installed on your device. Some data can be kept directly on it. But for certain services, the phone has to talk to the network.
LowFlow works on a similar logic. Local doesn't necessarily mean offline.
The application stays local. But it needs an internet connection to communicate with LowFlow's infrastructure and verify certain things it needs in order to run.
And the Control Panel showed up
From that point on, the project changed again.
I no longer had just an application. I now needed a place where I could manage everything happening around the application.
The Control Panel became that central piece. That's where I manage everything LowFlow needs commercially — accounts, licenses, versions, distribution, and the checks needed between the application and my infrastructure.
And it let me keep a clear separation. The trader keeps their data. I manage the product.
A required connection, but not a cloud journal
This is where the difference matters.
If there's no internet connection available, LowFlow can't just carry on as if nothing happened. The application needs to verify certain things with my infrastructure. Without that connection, it stays on the settings screen.
But the trader's data doesn't disappear — their trades, their photos, their history, and their replay data are all still there. The application simply isn't allowed to keep running normally until the required connection has been established.
That was the compromise I was looking for. The data stays local. Control of the product stays centralized.
I hadn't planned any of this at the start
And that's probably one of the most interesting things about this whole journey.
I didn't start LowFlow with some grand commercial architecture plan. I was building a tool I needed.
Then the tool grew. The journal grew. The features kept adding up. The addons showed up. The application became a real product — with a local app, local data, addons, potential clients, licenses, a Control Panel, an infrastructure, and a whole system that had to work together.
And eventually, in August, I had to face it. I could keep LowFlow local. But I could no longer manage everything around LowFlow purely from the client's computer.
I needed infrastructure. Not to take their data. Not to host their journal. But to properly run a product I now wanted to distribute to other traders.
A new stage
This is the point where LowFlow started looking a lot less like a simple piece of software I was building for myself.
And a new question showed up.
How do you make sure all of this can be delivered to the client automatically?
Because building software is one thing. Building a system able to deliver it cleanly to someone I don't even know is another.
And that's where the next stage of LowFlow was about to begin.