Why Most Manufacturing Software Sucks — and What We Do Differently at UMH

This isn’t one of my usual engineering deep dives, nor is it a marketing piece. Instead, I want to share the core principles that drive us on the UMH product team and explain why we’ve built our product the way we have. Read this article if you are interested about our product roadmap and how we differentiate ourselves from the market.

At UMH, our goal is to create an integrated and cohesive system for industrial IoT—much like how Apple designs products with the user experience at the forefront. We’ve focused our efforts on perfecting a single product: the Unified Namespace. By providing users with a seamless journey throughout their entire experience, we aim to set ourselves apart from the rest of the market.

In this article, we’ll begin by examining the common problems in typical manufacturing software today. We’ll then explain how our business model forces us to take a fundamentally different approach before finally explaining our product philosophy.

The Problems with Typical Manufacturing Software

Most manufacturing software solutions follow a familiar pattern.

Problem 1: Designed to Be Bought, Not Used

Typical manufacturing software often features (slightly outdated) user interfaces filled with an overwhelming array of buttons, dropdown menus, and wizards. These interfaces may look appealing to management during the purchasing phase, promising to “enable your workforce to do everything themselves” and ticking all the boxes in tendering processes. However, in practice, they often suck.

Why? Because the software is not designed for the actual users—it’s designed to be sold. The features may not work well or are cumbersome to use. Worse still, some features may have been developed specifically for a particular customer and then abandoned. This leaves the customer unable to update because their specific feature only works in older versions. Once the product is bought, vendors have little incentive to improve it for that customer. Instead, they focus on adding more features to attract new customers.

Few companies are challenging this approach. Most companies throw manpower at the problem, expecting that significant integration costs are just part of implementing new software systems.

Example: One of our customers was working with a well-known SCADA system. On paper, it could do everything. But in practice, it lacked basic usability features. The user couldn’t even perform a simple “copy-paste” routine. He had to manually type in all the tag names from his Excel sheet—taking weeks to complete and leading to inevitable mistakes. This not only delayed the project but also increased costs due to the need for additional system integrator support.

Problem 2: Not Designed for the Power User

To appear user-friendly and appeal to purchasers (see Problem 1), many manufacturing software products oversimplify their interfaces. They are very easy to get started with, which is great for initial adoption. But as the project moves from proof-of-concept to scaling, users become frustrated with the time-consuming process of configuring everything through the UI. Or they need a certain advanced functionality, which is not yet available in the product, and which now must be somehow put in using "quick fixes".

This often leads to outsourcing to system integrators (SIs) because “everything can be done with the product; it just takes time.” The SIs themselves may also become frustrated and prone to mistakes.

No-code tools are a prime example. They offer drag-and-drop interfaces that mimic programming structures like loops and conditions. But as you try to build more complex applications, the limitations show up. The visual code becomes messy and hard to manage. You’re essentially programming with a UI, but without the efficiency and clarity that code provides.

Example: Node-RED is great for simple tasks and getting started quickly. But it lacks features like templating, making it challenging to scale. You can’t create a simple “one machine connection flow” and then template it for the next 200 machines.

It Doesn’t Have to Be This Way

Over time, the purchased product becomes overshadowed by a growing pile of quick fixes and chaotic workarounds. Addressing these issues becomes difficult, as presenting a long list of trivial fixes to management is unappealing—especially when these fixes require “just a bit more effort.” The result is a solution that will never be truly effective and, at best, is merely “good enough.” Integration slows down, and costs escalate due to increased spending on system integrators and project management—often surpassing the original software costs and the value generated from it.

Eventually, the cycle repeats with a new product promising to solve it.

It doesn’t have to be like that. We know it. We have experienced it. We have been that system integrator. We have worked with the average manufacturing software solutions. But we have also worked with well-designed products that put the user first, like those from Apple, or the products Figma, Pitch or Linear. They don’t give you all the options that might work, but they give you one option that works.

We Built UMH to Break the Cycle

We take a whole different approach than most manufacturing software:

1. We are Open Source and have a free-to-use community edition (addressing Problem 1: Designed to Be Bought, Not Used).
2. We started by adopting IT/OT best practices and then made them more accessible to the average user (addressing Problem 2: Not Designed for the Power User).

Let’s explore these two points and see how they force us to take a different approach to the issues from the previous chapter.

Approach 1: We Are Open Source and Have a Free-to-Use Community Edition

This is addressing problem 1: Designed to Be Bought, Not Used. Traditional manufacturing software is often designed to appeal to management, leading to products that are sold but not necessarily used effectively. The reason being that the industry is currently still dominated by longstanding relationships and traditional networks. Often, purchasing decisions are influenced by established connections and trust rather than the quality of the product.

We don’t come from the traditional industry background or have years of established sales networks. We were young system integrators who found themselves in the harsh reality of the shop floor.

So we needed to do something different to break this cycle. We built a product and open-sourced it that inherently focuses on the user’s needs.

How Open-Source Business Models Work

In an open-source model, the core software is freely available for anyone to use, modify, and distribute. Companies adopting this model generate revenue by offering additional features, support services, or enterprise editions. Well-known examples include Red Hat, Grafana, MongoDB, TimescaleDB, InfluxDB and many more.

This model allows users to try the product without commitment, ensuring they only invest further if the software truly meets their needs.

How This Model Forces Us to Build Software Designed to Be Used

Because our software is freely available, users are under no obligation to continue using it if it doesn’t meet their expectations. This forces us to prioritize: We must create software that is genuinely useful and user-friendly to encourage continued use, and therefore also upgrading to the paid versions.

Conclusion of Approach 1

“Random people on the internet” are using UMH in production environments—not because they are mandated to, but because they find genuine value in it. We actively engage with our users through our Discord, and direct conversations, enabling us to address their needs promptly. User contributions and feedback have led to significant enhancements in our software, benefiting the entire user base.

This has resulted in a lot of unusual product decisions.

One example: getting data out of production machines. Usually, to do this, you need to be physically present. Not because it’s necessary, but because if you were to do it remotely, you would need to navigate complex corporate VPNs, virtual PCs, and remote desktop protocols from one jump host to another before finally accessing it via SSH. The mouse lag is unbelievable. I have not seen yet a lot of vendors going for this approach. Usually they rely on system integrators to do this hard work.

Instead, with the Management Console, you set up a UMH instance (or a UMH Lite instance at the production machine) once and can then remotely configure it securely with our end-to-end encryption (which is by the way patent-pending, a small success in my personal development career).

Approach 2: Starting with IT/OT Best Practices

This is addressing problem 2: Not Designed for the Power User. Small recap: To appeal to purchasers, many manufacturing software products oversimplify their interfaces. While these products are easy to adopt initially, they often fall short when scaling. Users become frustrated with time-consuming UI configurations and the lack of advanced functionalities, leading to reliance on “quick fixes”.

This often results in outsourcing to system integrators (SIs) because “everything can be done with the product; it just takes time.” The SIs themselves may also become frustrated and prone to mistakes.

We recognized this issue and took a different approach.

How We Started with IT/OT Best Practices

We started by building an infrastructure grounded in IT and OT best practices, with an end-to-end user journey in mind—contrary to building niche functionalities with a nice UI and expanding its functionalities.

Even if it meant being perceived as “too complicated” initially.

Yes, we were initially perceived as complicated. However, we knew that this approach had been proven countless times to scale, as it forms the foundation of almost all modern IT infrastructure. 

Just today, I came out of a meeting with a billion-dollar revenue company that uses Kubernetes/OpenShift on the shop floor. Additionally, I know of at least two German automotive OEMs adopting the same approach.

You can easily integrate our solution into GitOps workflows, version it with Git, work with ChatGPT on configurations, and template it using countless tools. If you encounter any issues, you can simply search for solutions—there’s a vast community and abundant resources available.

By starting with best practices, we ensured that power users wouldn’t hit dead ends. They have full access to the underlying configurations, allowing for advanced customization and scalability.

Making Best Practices Accessible

Understanding that not all users are comfortable starting with YAML files, we developed the Management Console—a user interface that helps generate these configurations. This simplifies the initial setup without requiring deep expertise in IT/OT practices, while still allowing power users to edit the YAML files directly if needed.

Why Pure UI-Based Approaches Fall Short

Pure UI-based solutions are easy to start with but often lack the depth needed for complex projects. Advanced features like GitOps integration, complex templating, and large-scale deployments are difficult to manage through a UI alone.

And vendors might unintentionally diverge from established best practices, leading to proprietary solutions that are hard to scale or integrate with other systems.

Without access to the underlying configurations, users may find themselves stuck when they need functionality that the UI doesn’t support.

Real-World Example

I had a good talk with Diederik, one of the “random people on the internet” using UMH a couple of days back. He was using another open-source project designed as a central UI. He really liked it—until the moment he needed a feature they wouldn’t deliver. He was stuck and couldn’t find a solution for his customer right at that moment, as there was no fallback option, no best practices to rely on.

He told us:

“Now I think I am getting what you are trying to do.”

- Diederik

This experience highlights the importance of having a system that is both user-friendly and robust enough for power users.

Our Approach at UMH

Building on our experiences and addressing the challenges we’ve identified, we’re focused on creating a manufacturing software solution that genuinely serves its users—both novices and power users alike.

A User-Centric, Integrated Solution

We prioritize putting the user first, much like well-designed products we use daily—such as those from Apple, Figma, Pitch or Linear.

Apple's Approach

Take Apple MacBooks as an example. Apple controls both hardware and software, allowing them to prevent issues like driver crashes or standby problems. You might have noticed that closing the lid on a Windows laptop and putting the laptop in your backpack can sometimes cause overheating due to misalignment between software and hardware (see "Laptops Will Not Sleep Anymore"). By owning the entire stack, Apple ensures a seamless and reliable user experience.

They also focus on meaningful innovation rather than following every trend. For instance, while many competitors are “throwing AI on everything,” Apple has quietly integrated AI capabilities into their products for years. Recently, they announced Apple Intelligence, providing applied AI in well-understood and effective contexts (source). Features like Writing Tools allow users to refine their text across various apps, enhancing productivity without overwhelming complexity.

Linear’s Opinionated Product Design

Another example is Linear—a project management tool that offers a streamlined alternative to platforms like Jira or Asana. Instead of building a generic system, Linear has developed an opinionated product that enforces certain product development processes. As they put it:

“At Linear, we don’t write user stories and think they’re an anti-pattern in product development. We write short and simple issues that describe the task in plain language instead.”

(Read more about their approach)

This focused methodology works incredibly well for teams that align with their philosophy.

Our Philosophy

We believe there are enough generic “do-it-all” IoT platforms out there. What’s missing is an opinionated product that allows you to perform specific tasks exceptionally well.

By putting the user first, we aim to provide a solution that doesn’t just offer a multitude of options but delivers the right options that work effectively and reliably.

However, UMH might not be the perfect fit for everyone, and we believe in being transparent about that.

Who UMH May Not Be Ideal For

Organizations Seeking Complete Customization. If you’re looking to fine-tune every aspect of your production infrastructure to meet highly specific or niche requirements, UMH might not align with your needs. Similar to how Apple offers a curated selection of hardware configurations rather than customizable laptops to meet 100% of every user’s unique specifications, we focus on providing a stable, well-integrated system that works reliably out of the box. While other vendors might offer extensive customization (like the myriad options available from Dell or Lenovo), this can sometimes lead to issues due to less thoroughly tested configurations.

Teams Unwilling to Adapt Established Processes. Drawing from Linear’s approach, their product is perfect for companies willing to embrace their streamlined workflows, but it may not suit teams that prefer to adhere strictly to traditional methods like Scrum with fully customized development processes.

Similarly, UMH is designed with certain best practices in mind. We aim to simplify and automate complex Industrial IoT tasks, which means we may not accommodate every bespoke process or methodology.

Focusing on One Exceptional Product

We initially started with a “toolkit” approach, offering multiple products. However, we realized that to truly make a difference, we needed to focus our efforts. That’s why we’ve dedicated ourselves to perfecting a single, exceptional product: the Unified Namespace.

By focusing on one core offering, we ensure that it not only meets but exceeds the needs of our users. We’ve paused the development of new features for our other products, such as the Historian and the IT infrastructure components around Flatcar, to devote all our resources to the Unified Namespace. Once we’re confident that we’ve perfected it, we’ll return to those products and give them the attention they deserve.

Instead of stacking niche features, we’re building infrastructure with a grand vision in mind. We aim to automate as much complexity as possible, providing an end-to-end journey from connectivity to value capture.

We are not perfect yet - we know it

No, this is not self-praise—we know we have not yet fulfilled our product vision. There is still much to do, but I hope that with the background information from this article you can better understand why we are doing the things we do.

Example 1: Balancing Simplicity and Power In Our Protocol Converters

We understand that our current protocol converters, with their Bloblang approach, might seem overwhelming at first—especially for those coming from an OT background. They offer a lot of capabilities, from base64 decoding to compression and Sparkplug-B decoding to renaming your tags (see examples here). But they can also feel overwhelming.

To address this, we’re proposing an easier alternative that reduces the need for programming and allows for pure configuration (check it out here).  This new approach retains the full flexibility that power users require while making it more accessible for those less familiar with programming concepts. Our goal is to continuously simplify IT/OT best practices without compromising on power or scalability.

Example 2: Templating In Our Protocol Converters

We acknowledge that setting up protocol converters for hundreds of production machines can be time-consuming at the moment. While we’ve simplified the connection process for individual machines to under a minute—such as auto-negotiating OPC UA connection parameters and auto-subscribing to entire folders—we know there’s more work to be done for large-scale deployments.

In the meantime, there’s a practical workaround - a fallback option to well established IT / OT best practices.

You can take the central YAML file (mgmtcompanion-config), use a tool like ChatGPT to generate a script in your preferred programming language, and automate the creation of multiple protocol converters.

Our overall product approach ensures you’re never stuck waiting for us to add a feature.

A Collaborative Path Forward

We don’t claim to have all the answers, and we recognize that there’s still much to achieve. However, we’re confident in our direction and our dedication to creating a product that genuinely addresses the problems we’ve discussed.

Our vision is not about providing every possible option but about offering the right options—the ones that work effectively and reliably and that scale.

Conclusion

By aligning our approach with the challenges identified in the industry, we’re striving to deliver a manufacturing software solution that breaks the cycle of ineffective tools. We’re not here to be arrogant or claim superiority; we’re here because we’ve been in the trenches, we’ve seen what doesn’t work, and we’re committed to making it better.

We were young system integrators who found ourselves in the harsh reality of the shop floor, determined to make a difference.

Don’t believe me? Try it our yourself