Industries
Software quality in Manufacturing
The web layer of a manufacturing system is judged by people who use consumer software all evening and shop-floor software all day. It is usually built with a fraction of the attention, on top of systems that predate it by a decade.
What shapes Manufacturing software
What tends to go wrong
Internal tools are held to consumer expectations by the people using them, but are usually built and tested with a fraction of the attention.
The web layer sits on top of systems that predate it, and the integration is where the data goes stale or wrong.
Dashboards are trusted by default: a number that is quietly incorrect is worse than a page that is visibly broken.
Users are on shop-floor hardware and older browsers, not on the laptop the tool was demonstrated on.
What binds you
Cyber Resilience Act
The one most likely to change how you work. It covers products with digital elements placed on the EU market, which includes connected machinery and the software shipped with it: security by design, vulnerability handling for the support period, and an SBOM. Reporting of actively exploited vulnerabilities starts 11 September 2026; full application is 11 December 2027.
NIS2
Annex II names manufacturing of certain products — medical devices, computers and electronics, machinery, motor vehicles among them — as important entities above the size threshold. Lighter supervision than essential entities, the same underlying duty to manage risk and report incidents.
Machinery Regulation (EU) 2023/1230
Applies from 20 January 2027 and, unlike the directive it replaces, addresses software that performs a safety function and machinery with self-evolving behaviour. If your web layer can influence a safety-relevant parameter, the boundary between “internal tool” and “regulated component” is worth establishing early.
Engineering practice, not legal advice.
How we work on it
What that means in practice
We build the web layer — portals, dashboards, internal tooling — as a maintainable application rather than a one-off, and we test it against the environments it will actually run in, including the older browsers and the hardware on the floor. Where it reads from existing systems, we test that boundary explicitly so a stale or malformed feed is caught rather than displayed.
Related reading
- Accessibility
The European Accessibility Act and your website: what it actually requires
The Act has applied since June 2025. What it covers, which technical standard sets the bar today, and the accessibility failures no automated checker will ever find for you.
- EU regulation
The Cyber Resilience Act’s first deadline: what changes on 11 September 2026
From 11 September 2026, manufacturers must report an actively exploited vulnerability within 24 hours. Who that binds, what the clock actually demands, and what to have in place before it starts.
- Quality assurance
How to write a bug report a developer can act on
A defect report is a handover of an unfinished investigation. Most of them fail in the same three places, and none of the repairs involve a longer template.
FAQ
Manufacturing questions we hear often
Our internal tools are not customer-facing. Does the same standard apply?
The regulatory standard often does not; the usability one does anyway. The people using an internal portal for eight hours have the same expectations they have everywhere else, and the cost of a bad internal tool is paid in slower work and workarounds rather than in churn — which is harder to see and just as expensive.
How do you test against a legacy system we cannot change?
At the boundary. The integration point gets explicit tests for stale, malformed and missing data, so the web layer fails visibly rather than displaying something wrong. You do not need to modify the legacy system to assert what your own application does when its feed misbehaves.
Users are on old browsers and shop-floor hardware. Is that a problem?
Only if it is discovered late. It is a constraint like any other, and the answer is to establish it before the build rather than after: target the browsers that are actually deployed, test on representative hardware, and keep the application light enough to run on it. Retrofitting that is much more expensive than designing to it.
A dashboard number was wrong. How do you catch that?
By testing the calculation and the feed separately from the rendering. A dashboard is trusted by default, so a quietly incorrect figure does more damage than a visibly broken page — which means the assertion belongs on the value, against a known input, rather than on whether the chart appeared.
Contact
Building for manufacturing?
Tell us what you are shipping and where it worries you. You will get a considered reply from an engineer, not an autoresponder.