In the world of warehouse automation, technology is constantly progressing along with user expectations, which may evolve even faster. There are applications that have grown in functionality through multiple iterations. Such software usually has a lot of features and a lot of configurations. Although, when the number of configurations becomes bigger, a user should be much more qualified too. Otherwise, this may become a barrier to demanding too much from the user.
That was the case with the Cubiscan dimensioning system. Their solution provides advanced dimensioning hardware paired with a software application intended to manage a wide range of scenarios with highly customizable options. That’s the type of solution that allows it to be as agile as possible. But as the user base expanded, it became clear that different environments required different tools. Some clients didn’t need deep customization. They needed something faster, simpler, and easier to start with.
It generally reflected remarks such as “the hardware works great but setting up the software takes too much time” or “it feels like it is built for an expert, not for everyday use”. Thinking about it, I would find it not a criticism of the product but an invitation.
Instead of refactoring what already worked well for users that needed it, IntherGroup saw a chance to build something new alongside it. Something lighter, cleaner, and focused on the essentials.
That’s when our team got involved. There were just 2 developers Anna Hirjeu, as a Senior and me as Middle. Together we started looking into the main problem. At that time, we were not quite experienced in this specific domain, and neither had the experience of creating such hardware-based applications. Luckily, there were some internal frameworks we found to work with. But a bit later about that.
At first it looked like a challenge. We had no access to the Cubiscan hardware here in Moldova. The Cubiscan hardware was located in the Netherlands, and a lot of kilometers separated us from it. You might think of sort of remote connection, but it would be too difficult and expensive to arrange that. That’s the question of time for our colleagues for each small test. Quite a lot. Thus, that was not quite an option.
That made things more complicated. Without access to the hardware directly, we had to rely on either documentation or on the original developers of the Cubiscan software. Since we could not communicate with the original developers efficiently, the only source left was the documentation. Honestly, when we first read it, it sounded like a foreign language due to lack of experience in the domain. Reading it 5 or 10 times wouldn’t help much. With no one available to clarify, we applied our best perseverance and a fair amount of educated guessing. Imagine our surprise when we realized that some documentation simply wasn’t written with such cases in mind. Deciphering it felt less like reading a manual and more like solving a riddle, assembling a puzzle, or playing an escape room without clues.
As we negotiated with Anna, I started working on the back-end part and Anna on the front- end part. However, the project itself should have had the feel and look of the Inther application. And that would require creating all the designs from scratch. Luckily, there was an internal framework adapted from AFrame solution. Even though it helped us with look and feel, I needed to adapt it for our case. Newer java, proper dependencies, needed web pages, tabs, etc. After coming through this step, Anna would be able to continue with the front-end.
The communication with Cubiscan hardware was on back-end, so I started with it. In short, there were commands, commands’ syntax, length, and codes. It communicated with the PC by using a TCP stream. At first, I thought it was possible to somehow send a command and then accept a single result and then close the stream. Then extract from the result dimensional data, weight, etc. That was the first algorithm. Assuming this, we finished both back-end and front-end parts.
There was a work trip planned then. So, we could test everything on a real Cubiscan device. Here came another problem. Connecting everything properly. All the cables for Cubiscan, a camera, and network. There were quite a few days spent out of a single week planned. When everything was connected, we tried the communication algorithm… And it failed… Of course! Because that model of Cubiscan had a special gate that should be moved manually. And it was not required to send a command to the Cubiscan to do a measure, we should have just waited for a result…
It was not possible to finish all the work by making a fully workable algorithm in those days left. So, we decided to at least make it work somehow. To just receive a few messages, understand what is inside the command received and continue back in Moldova. There were a lot of details found. Starting from some differences between the real data and the one in the documentation and finishing with the way the data is sent.
Considering the real test data now, we have managed to build the correct version of the algorithm. And then we were able to continue with the rest of the tasks. Implementing a lightweight solution by bringing only the core functions. We would spend time understanding what the original software does and how to adapt it to our case. And to adapt the UX to be comfortable for the user.
On the next work trip, we tested a new version of communication algorithms. This achievement allowed us to not being dependent on having the Cubiscan at hand and to be able to develop new features remotely.
The result was a modern, lightweight application that integrates seamlessly with Cubiscan hardware while simplifying the entire experience. The main differences between the apps were as follows. The original full-featured version remains for the need of advanced configurations. The lightweight version delivers a simplified interface for everyday operations and quick setups having the most core features. Together, they give clients the choice. They may decide to pick the solution that best fits their workflow.
As technology providers, we often focus on building capability. This project reminded us that innovation isn’t always about adding more. Sometimes it’s about truly listening, removing what’s unnecessary, and designing with real people in mind, each with their own needs, perspectives, and ways of using a product. Simplicity, when done right, isn’t a limitation but a competitive advantage.
How do you balance power vs simplicity in your products? I would love to hear your thoughts.
