How PSS built a digital manufacturing culture with a custom Mendix MES

For Stijn Van Uytfanghe, Global Digital Transformation Manager at PSS, the answer was a step-by-step approach built around the people on the floor and a modular Manufacturing Execution System (MES) that could grow with them.

‍

The starting point

PSS builds speakers for automotive and consumer goods customers worldwide. The complexity sits in the variation: a wide range of speaker types and sizes, each with their own assembly process and specifications.

Paper couldn't keep up with the traceability requirements automotive customers demand. Whiteboards tracked shift performance but were wiped at the end of each week. The SAP system collected data, but wasn't built to guide operators through their work.

When Stijn Van Uytfanghe joined PSS in 2022, his vision was concrete: go paperless, support people on the factory floor. in doing their work well, and build a system that structurally reduces issues and waste rather than catching them after the fact.

That ambition needed a partner with real manufacturing knowledge, technical expertise and willingness to embrace the agile way of working.

‍

‍

From day one, the approach was co-creation: mapping processes with key users and working closely with PSS's own development team to make sure what got built reflected how their plants actually ran.

‍

Starting small on purpose

The first project together was a changeover app: a tool that guides operators through machine settings and work instructions when changing to another product. Across six plants with varying line configurations, that process had previously lived on paper and based on people's experience. Before a single line of code was written, we followed the process on the factory floor, we discussed with the key users on how the process actually worked and how it could be improved. What did operators need to see? In what order? What could go wrong? That functional groundwork shaped everything that got built.

Early results on the first production line pointed to an estimated 10% decrease in downtime.

In parallel, PSS started an experiment that captured exactly their vision. They built a digital version of one of their production whiteboards themselves. The first test with operators was a success. A shift leader recognised his board in the developer’s office on a 86-inch touchscreen, started clicking, and before the session was over was already telling the team what else he'd change.

That response confirmed the direction. Together, PSS and Mayker worked through the UI/UX and the positive feedback from operators only grew.

From there, PSS's own development team kept building. More tools, more processes, always driven by the same question: what are operators dealing with that the current setup doesn't support?

‍

Building a custom MES

The standalone apps worked. But automotive customers were raising the bar on traceability, wanting to know exactly which data was linked to every speaker, every pallet, every shipment. Four different legacy MES variants were running across the six plants, none of them connected to SAP Data had to be manually re-entered across systems.

"Without that MES foundation, you cannot sustain those customer expectations," said Stijn.

A standard off-the-shelf package wasn't the answer. Beyond the cost, an estimated one million euros or more in licences and customisation, it would mean handing control back to a vendor's roadmap. For Stijn, that was a fundamental problem: building a culture where operators shape the system only works if the system can actually respond to them.

PSS made a deliberate choice: to build their own MES on Mendix rather than buy one off the shelf. It meant taking ownership of the roadmap, the architecture, and the pace of development. Together, we crystallised the user stories with key users, designed the global cloud architecture and built the SAP interface. It took only nine months from analysis to go-live.

The rollout followed the same logic as everything before it. Rather than switching every plant at once, they started with a single pilot line per location. Operators used it, shared feedback, and the application improved before moving to the next line.

What keeps the system moving forward is a direct line between the floor and the development team. Operators can flag feedback through the applications, and if it adds value, it gets implemented fast.

‍

‍

The collaboration extended further. We also built the interface for PSS's fleet of AMRs, logistics robots that transport components from warehouse to production line and move finished pallets out.

‍

The results

The impact was immediate. The MES now validates every pallet before it leaves the line. If something's missing, the operator can't proceed. Every speaker PSS produces is scanned, validated, and fed back into SAP without manual re-entry. 120 million speakers a year, each one tracked, and when the pace drops, the data shows it immediately.

PSS runs their Mendix applications from the Mendix Cloud in Frankfurt, accessible to teams across Belgium, Malaysia, Mexico, Hungary, Germany and China. Connecting that global setup to machines inside each local plant, within the IT constraints of every country, is exactly the kind of challenge where Mayker's technical expertise made the difference. The result: every plant now works the same way, with the same tools, the same output format, and the same rules.

"We have more effective data. We can act on data rather than opinions."

To make it concrete: a 10% increase in production line output through daily improvement initiatives and 30% fewer customer complaints since the MES rollout.

But when Stijn talks about what actually changed, he doesn't start there. He talks about shift leaders.

‍

‍

That's the result of building step by step, starting from the process, and keeping operators at the centre of every decision.

Practical lessons from manufacturing sites: when standalone Node-RED is enough and when you need FlowFuse

‍

‍

Many factories start with Node-RED and do great. One use case, one engineer, one site — it just works. Then a year passes. A second site gets added. A third engineer joins the team. A compliance audit lands on the desk. And suddenly, things get messy.

At Mayker, we work with both every day. We're not selling either product, we're integrators who need to make it work on the factory floor. After dozens of implementations, we've developed a clear sense of when standalone Node-RED is enough, and when FlowFuse becomes the better choice.

This is what we've learned.

‍

What does Node-RED actually do?

Node-RED is an open-source integration tool. Visual, low-code and event-driven. You connect blocks: if this, then that.

But "if this, then that" can be surprisingly powerful. Take a sensor counting products on a production line. On its own, that's just a number. But calculate the time between products, and suddenly you're detecting micro-stops. Add a threshold, and you're flagging anomalies before anyone notices. Combine it with operator data, and you know who was on shift when something went wrong.

That's what Node-RED does: it takes raw data from machines and sensors, enriches it with context, and turns it into something useful. From "a product passed" to "the line stopped for 5 seconds during operator X's shift."

It's free, flexible, and great for prototyping. For a single use case or proof of concept, it's excellent.

‍

What is FlowFuse  and how does it relate to Node-RED?

FlowFuse is built by the initial core team behind Node-RED, but designed for production environments. Same Node-RED engine underneath, but wrapped in everything you need when you're no longer prototyping:

• Version control: see who changed what, when, and roll back if needed
• Role-based access: operator X can view dashboards, engineer Y can edit flows, manager Z approves deployments
• Central management: one overview of all your instances across sites
• Audit trails: essential for NIS2 and other compliance requirements
• Fleet deployment: update dozens of instances at once instead of one by one

Think of it this way: Node-RED is the engine. FlowFuse is the garage, the maintenance schedule, and the fleet manager,  all in one.

Node-RED and FlowFuse in practice: four use cases

We've implemented both tools across different customers and situations. Sometimes FlowFuse was the obvious choice, sometimes standalone Node-RED still does the job.

‍

Detecting micro-stops with FlowFuse across 7 sites

A food producer wanted better visibility into their packaging lines. Sensors were already counting products, but the raw numbers didn't tell them much.

We designed a standardized flow that calculates the time between products passing. If that gap exceeds a threshold, it's flagged as a micro-stop. We enrich each anomaly with timestamp, production batch, and operator on shift,  turning a simple count into an actionable insight.

This now runs across 7 sites worldwide: Belgium, Thailand, the US, and more. Same code, developed once, deployed centrally. When we improve the logic, it rolls out everywhere. With standalone Node-RED on each site, we'd be managing 7 separate versions with no guarantee they're in sync. FlowFuse made central deployment and version control possible.

‍

Multi-site harvest workflow with FlowFuse

Harvest season at a vegetable processor means two months of trucks arriving non-stop. Farmers want to dump their load and get back to the field, fast.

We built an operator app on the weighbridge. The farmer enters their ID, the system captures weight and license plate automatically, and assigns a silo based on product type and available capacity. What used to be chaos — trucks waiting, wrong silos, lost paperwork — became a structured flow.

This app runs on three sites. Updating one means updating all three. With standalone Node-RED, that's three manual interventions and three chances for version drift. With FlowFuse, we deploy once and push to all locations. We see at a glance that all three run identical code  and when harvest season ends, we know exactly what version ran where.

‍

Energy monitoring across sites with FlowFuse

A vegetable processor operates two freezer warehouses, each with its own energy bill but no way to compare consumption patterns or spot inefficiencies across sites.

We stream energy data from both locations to a central FlowFuse instance in the cloud, where it's aggregated and visualised. The insight that emerged: running freezers at -13°C costs nearly twice as much as -12°C. For most products, that one degree doesn't affect quality  but it cuts the energy bill significantly.

You could run a standalone Node-RED instance in the cloud for this. But then you're back to manual management: no central overview of what's running where, version control or SSO. FlowFuse gives us a managed environment where cloud instances and edge devices are visible and controllable from one dashboard.

‍

ERP-to-machine integration with Node-RED

At one food processor, Node-RED handles the translation between ERP and machines. Purchase orders come in, get translated into production instructions, and the line runs.

They're not using FlowFuse here. Why? They have a dedicated IT/OT person who manages all instances. One person, full overview, no handovers.

It works  but it's fragile. That knowledge sits in one head. When that person is on holiday, nobody touches the system. When they leave, there's a problem. We see this pattern often: Node-RED works fine until it doesn't, and by then migration becomes urgent rather than planned.

‍

Signs your Node-RED setup is reaching its limits

Over time, we've noticed a few recurring situations that push teams towards FlowFuse:

"Who changed this?" At one customer, this question comes up every single day. Someone modified something, something stopped working, and there's no trace. In standalone Node-RED, there's no version control, no audit trail, no way to look back three months and see what happened. With FlowFuse, every change is logged: who, what, when.

Overwriting each other's work Multiple people working on the same flows. Someone deploys, someone else was also editing. Work gone. In Node-RED, you can't even see that someone else is online. We've seen this happen daily at manufacturing clients. With FlowFuse, you see each other's cursors in real-time, and deployments require approval.

Manual updates across sites One building materials company ran Node-RED on over 100 sites worldwide. Every software change had to be executed manually — a hundred times. That's not scalable. With FlowFuse, you deploy to development, test, approve, and roll out to all production instances in one action.

Access through jumpservers and RDP Excuse us for going a little technical here. At one customer, engineers needed a jumpserver and RDP session before they could even reach their Node-RED instances. Key users couldn't access anything without IT support. FlowFuse offers SSO integration and browser-based access — the right people get to the right instances directly.

We've seen this go wrong firsthand. At one customer, two sites were running different Node-RED flow versions for months, different alarm thresholds and nobody was aware. It caused significant inconsistency in quality comparisons across plants. The kind of problem that's invisible until it does real damage.

‍

Node-RED vs FlowFuse: when to choose what

Our rule of thumb:

• One instance, one person, one goal? Standalone Node-RED is fine.
• Multiple people, multiple sites, or compliance requirements? FlowFuse saves you time and frustration.
• Not sure how many instances you'll have in a year? Start with Node-RED, but standardise from day one with consistent naming conventions, units and topic structures. That makes a future migration to FlowFuse straightforward rather than a rebuild.

‍

See it yourself

In our demo factory in Ghent, FlowFuse runs on 20+ instances. If you want to see what this looks like when it's actually running, you're welcome to pay us a visit.

Let us know!

‍