As LowFlow kept growing, it started to feel like a real product.
A local application.
Data that stays with the trader.
An automatic update system.
A Control Panel.
Licenses.
An infrastructure that let the application talk to my system.
Everything was starting to work together.
But a new reality became obvious.
The bigger the system got, the more it needed to be protected.
At first, security wasn't top of mind
When I was building LowFlow just for myself, the question was much simpler.
I wanted the software to work.
I wanted it to be fast.
I wanted it to never crash.
I wanted to add my own features.
I wanted to improve my journal.
Security wasn't at the center of my days.
But the moment an application becomes a commercial product, everything changes.
It's no longer just about protecting my own files — it's about the clients, the licenses, the updates, the distribution system, and the infrastructure behind all of it.
A distributed application isn't the same thing anymore
When LowFlow stays on my computer, I control everything.
But once the application is installed on someone else's computer, I no longer directly control that environment.
The application itself needs to be able to verify certain things.
And my infrastructure needs to be able to verify other things remotely.
That's when I started building several layers of protection.
I didn't want to put all the security in one single place.
Because a single protection can always eventually be bypassed.
So the idea was to multiply the checks.
Protecting the licenses
The first thing to protect was obviously access to the product.
I wanted to avoid a license simply being copied from one computer to another with no control.
LowFlow needed to be able to recognize the installation using the license.
And if something didn't match, the system needed to be able to detect it.
That led me to work on machine identification and on managing transfers.
The goal wasn't to stop a client from changing computers.
The goal was to be able to handle that change properly.
Protecting the updates
Then there were the updates.
This had become one of the most important pieces of the system.
If LowFlow could automatically fetch a new version, I needed to be certain that version really came from me.
An update isn't just a file.
It's something that's going to run directly on the client's computer.
So I wanted every distributed version to be verifiable before installation.
Distribution needed to be controlled.
The server had to be protected too
Now I had another problem.
I was building infrastructure that needed to be reachable by the application.
But I obviously didn't want to expose my entire infrastructure to the internet.
I had to limit what was accessible.
Limit which functions were exposed.
Monitor the requests.
And above all, be able to notice when behavior didn't look like what was expected.
So I started adding controls in several places.
Not a single barrier.
Several.
Security becomes an architecture
That's probably when the way I saw the project changed.
I stopped thinking: "How do I secure LowFlow?"
I started thinking: "How do I make sure a single weakness never compromises the whole system?"
That difference matters.
The application has its own checks.
The server has its own.
The licenses have their own validation.
The updates have their own verification.
And certain information can be monitored on the server side.
All of it works together.
But I didn't want to turn LowFlow into a cage
I also had to keep a certain simplicity.
I didn't want the trader to feel like they were using a complicated piece of software full of checks.
They just needed to open LowFlow and get to work.
The system needed to do its job in the background.
That's probably one of the hardest things to do in software: building something complex so that the user never has to see that complexity.
The trader doesn't need to know the mechanisms protecting their installation.
They just want LowFlow to work.
And my data stays local
Despite all this new infrastructure, I always came back to the same principle.
The trader's data didn't suddenly become mine — it stays exactly where it's always been, on their machine, whether that's their trades, their photos, their history, or their replay data.
The security added around LowFlow doesn't change that philosophy.
It mostly protects the product and how it operates — not the client's trading life.
Another lesson from building this
The more I build LowFlow, the more I discover that every new feature brings along several consequences I hadn't thought about at first.
I wanted automatic updates.
That meant building infrastructure.
I built the infrastructure.
That meant protecting it.
I added the protections.
Then I had to think about something else: how to make this whole system run automatically enough that I could actually manage clients.
Because at the end of the day, my goal wasn't to spend my days sitting behind the Control Panel.
I wanted to keep developing LowFlow.
And for that, the system needed to work for me.
The next step, then, was automation.
Building a system able to do almost all the work by itself.