Building the app was one thing.
Getting it to run on my own machine was another.
But now I wanted a stranger to be able to buy LowFlow, receive access, install the app, and start using it.
And that's when it hit me: I wasn't just building software anymore. I was building a system capable of delivering software.
The client shouldn't have to email me
I wanted to avoid the classic scenario. A client buys. They email me. I reply. I send a file. I explain how to install it. Then they come back because they changed computers. Then again because they want an update. And so on.
If I wanted dozens, then hundreds of clients, that model couldn't work. I had to automate as much as possible. The client needed to be able to purchase and receive what they needed without me having to step in manually at every stage.
The client account
So I had to start at the start. An account. The client needed to be identifiable in my system. Their purchase had to be tied to their account. Their access had to be tied to their product. And their app had to be able to communicate with that information.
It looks simple from the outside. But behind a small login screen, a lot of things have to line up — the right client, the right product, the right license, the right version, and the right device.
The license
Then came the question of the license. I didn't want to just send an executable and say, "There you go, have fun."
LowFlow needed to know whether the person running it actually had valid access. The license became a central piece of the system. It ties the client to the product they bought and manages their access over time.
But again, I wanted to keep the same philosophy. The journal stays local. The license, on the other hand, is verified remotely.
And the installation?
Then I had to distribute the app. I wanted to avoid putting my production files out in the open for anyone to grab. So I had to build a system where the client could get the right version of LowFlow without exposing my entire development setup.
That's where my Control Panel started to matter even more. It became the management hub for everything that needed to be distributed.
A version isn't just a file
At first, you might think an update just means swapping an old file for a new one. In reality, it's not that simple.
You need to know which version the client is running. You need to know which version is available. You need to be able to verify that the file received actually matches what should be installed. And you need to prevent a client from downloading just anything.
So I started building a much more structured chain: a version, a check, a distribution, an installation, then a new version when needed.
I wanted it to work without me
That was probably the most important part. I didn't want to build a business where every new client became a new manual task. I wanted to build the system once. Then let the system do the work.
The client buys. Their access is created. They get the app. The app talks to the infrastructure. The license gets verified. And LowFlow starts.
Anything that can be automated should be. Because my goal isn't to spend my days sending files and activating licenses. I want to build LowFlow.
And what about updates?
Once distribution was sorted, another question became obvious. What happens when LowFlow evolves? Because LowFlow keeps evolving. A fix today. A new feature tomorrow. An optimization next week.
I couldn't ask every client to manually download a new version every time something changed. So I had to think about updates from the start. The app needed to know when a new version was available and fetch the right one when needed.
Once again, the goal was the same: the least amount of intervention possible.
The system was taking shape
By this point, LowFlow had several pieces that had to work together: the local app, the trader's data, the client account, the licenses, the Control Panel, distribution, updates, and the infrastructure letting all of it talk to each other.
And yet, the core of LowFlow hadn't changed. The trader still worked with their own data, on their own machine. I hadn't turned the journal into a SaaS. I had simply built around the local app what I needed to sell it properly.
But a new question showed up
The more I built out the system, the more one reality became obvious. If I really wanted to distribute LowFlow to clients, I had to protect everything I'd just built.
Not just the app. The license. The updates. The distribution. The infrastructure.
And above all, I had to make sure the system could tell the difference between a legitimate install and something that had no business having access to the product.
I had just finished one stage. And I was about to find out the next one would be a lot more serious. Protecting LowFlow.