My customers often analyze the potential of employing custom IoT solutions for businesses. The decision to invest in building them is not a simple one. It requires careful consideration of short-term, mid-term, and long-term aspects and operational capital management. Short-term Reasoning In the short-term, investing in custom IoT solutions may not be the most cost-effective approach. The upfront investment required to develop a custom solution can be substantial, and the benefits may not be immediately apparent.

Today, I’d like to share my thoughts on a topic that is crucial for any IoT project: codifying domain knowledge. When it comes to IoT, the ability to quickly and accurately translate human experience into software (often called “codifying domain knowledge”) is essential. It’s important to approach this task with care, but also with a sense of urgency. Based on my experience, starting quick-and-dirty reduces the risk of failure and leads to the best results.

Intro Often, I meet people who are unwilling to provide tangible outcomes, hiding their lack of skills under the guise of a research project. This misconception can lead to confusion, misaligned expectations with business stakeholders, and ultimately result in unsuccessful collaborations. Commercial Engagement vs. Research Project A commercial engagement is a partnership between a business and an external entity (such as a consulting firm, research institution, or individual) aimed at achieving specific, measurable outcomes that directly contribute to the business’s success.

Note In this article, I elaborate on the risk of vendor locking and how careful solution design helps prepare for the emergency. To be honest, that is not the main benefit of owning a business-tailored IoT solution, and this topic emerged on its own during the writing process. First, I considered it a side track, but then I realized it is an important perspective to share with you. Enjoy this text and share your experiences with me!

The Prologue In the beginning, no one really knows what they truly need. We call it the discovery phase when business domain knowledge clashes with the solution design mindset. We discuss the business aspects and random technical capabilities that may or may not be relevant to a given case. You start questioning the reason for this initiative, and you might be right. At the end of a few cycles, there are no tangible outcomes.

Recently, I had to significantly redesign the database structure of an IoT platform I designed one month ago. Changing the database forced the adaptation of the backend logic*, which demanded my extra attention and careful testing. During that change, I was constantly questioning my initial reasoning and my ability to design solutions. “That was obviously a wrong decision! Why does that setup not support this access pattern?!?!" Once my frustration level dropped a bit, I had yet another reflection - “There was no way I could have predicted all of that one month ago”.