My things

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...

Why the future of Customer Intelligence depends on signals, not surveys For many years, companies have treated customer understanding as something that needs to be requested. Want to know whether the customer enjoyed the purchase? Send a survey. Want to know whether support solved the problem? Ask for a rating. Want to measure loyalty? Ask the customer whether they would recommend the company. Want to understand why somebody cancelled? Add a cancellation questionnaire. There is nothing inherently wrong with this approach. Asking customers questions remains one of the most direct ways to understand their experiences. But it creates an important blind spot. Customers communicate with companies constantly, including when nobody asks them anything. A customer who attempts checkout five times is communicating something. A customer who suddenly stops using a product is communicating something. A customer who contacts support three times about the same problem is communicating something. A cu...

After finally moving into our unfinished house on Friday, followed by another busy Saturday dealing with gas pipes and moving belongings, one might reasonably expect Sunday to be a day of rest. Well, not quite. There is still so much to do outside that spending an entire day doing nothing seems almost impossible. Every time I look around the property, I find another corner that needs cleaning, another pile of rubbish that needs removing or another old structure that should probably have disappeared years ago. Today, I decided to attack one of those structures: an old, thoroughly deteriorated wooden shed at the back of our property. As usual, the plan sounded considerably simpler before I started. But Sunday is supposed to be a day of rest! Since arriving in Moldova, I have repeatedly heard that Sundays are not supposed to be working days. At least, that is the position of Vita's parents, who are very devout Orthodox Christians. In their understanding...