As I move further into the development of my event-planning desktop application, I am reaching a part of the project that has nothing to do with C++ classes, Qt widgets or file formats. I need to decide how the product could eventually make money. That question sounds simple. Build software, choose a price and sell it. In reality, the business model influences quite a few technical decisions: licensing, update delivery, account management, documentation, cloud infrastructure, downloadable content, localisation and possibly even how much server-side functionality I want to introduce. There is also a principle I want to preserve from the beginning. This is intended to remain a real desktop application. I do not want to turn it into SaaS simply because recurring revenue is attractive. The user should be able to install the application, create an event, work on it locally and retain control of the resulting files. That does not prevent online service...
Based on a LinkedIn post originally published on 1 April 2026 The toolset used on my home-lab platform is intentionally small and purpose-driven. Tools are selected to help me understand, diagnose and operate the system. They are not introduced simply because they are popular, provide an attractive interface or promise to automate another part of the environment. Each tool must answer a specific operational question. The objective is not to own the largest toolbox. It is to ensure that every tool has a clear role and makes the platform easier to understand. Tools create operational architecture A tool is never completely external to the system it operates. Once introduced, it creates dependencies: someone must install and update it; its configuration must be protected; its access model must be understood; its output must be interpreted; and operators may gradually become dependent on the view it provides. A new tool may simplify one task while increasing the complexity of the overall p...