Every few months a plant contacts us with the same sentence: "We bought a solution and it does not do what the demo showed." It is not that the vendors are dishonest. It is that a product optimised to be sold to a thousand plants cannot be optimised for yours. This is a short argument for a different model, and an honest account of where it is and is not the right choice.
The product trap
A product has to work out of the box. That forces three design decisions. The models are trained on a reference library, so they encode assumptions about machines and environments that may not match yours. The sensors are fixed, so the product measures what it was built to measure rather than what your failure mode radiates. And the success criteria are defined by marketing, so the demo highlights the cases where the library matches, which is exactly the situation you will not be in.
The result is a system that is impressive on the reference machine and fragile on yours. Distribution shift, in the language of the research community, is the rule in manufacturing, not the exception.
What co-development means in practice
Co-development is not consulting with a different name. It is a way of running the project so that the system is built against the client's process from day one.
- Joint problem definition. Your process engineers and our engineers write the success metrics together. Detection lead time, false-alarm budget, which defects count.
- Measurement plan on your machines. Sensor selection, placement and synchronisation are designed for your line, often starting with sensors you already have.
- Dataset engineering you own. Label specification, quality assurance, versioning. The dataset stays with you and is reusable for the next project.
- Honest evaluation. Strong baselines, ablations, realistic test conditions, a go / no-go gate before any large spend.
- Production plan and handover. Edge deployment, integration with PLC, SCADA or MES, and training for your OT/IT team.
Our partnership with NeuroControls GmbH closes the hardware gap: when multi-modal data is needed, we co-develop the sensor unit and the model as one team, rather than buying a sensor and hoping the model can cope.
When a product is the right answer
We would be giving bad advice if we said co-development always wins. If your problem is a standard one, on standard assets, with a well-understood signature, a good product will be cheaper and faster. Bearing monitoring on large motors is a good example. Buy the product, keep your money for the hard problems.
Co-development pays off when the problem is specific (a defect on your process), the environment is hostile (noise, drift, multiple plants), the data must stay on site, or the previous attempt failed. In those cases the cost of a generic tool is not the licence fee. It is the year you lose finding out that it does not work.
How to tell the difference on a sales call
- Ask what happens when the model is wrong on your machine. A product answers "it learns"; a co-development partner answers with an evaluation protocol.
- Ask who owns the dataset and the model after the project.
- Ask for the go / no-go gate. If the project cannot fail, be suspicious.
- Ask for published methods. Peer review is not a guarantee, but it is evidence that the approach survived scrutiny.
Key takeaways
- Products encode assumptions about machines and environments that rarely match yours; distribution shift is the rule.
- Co-development builds the system against your process, with metrics your engineers sign off.
- Own the dataset and the model; they are assets that outlast the project.
- A product is the right choice for standard problems on standard assets.
- Ask vendors about failure, ownership and go / no-go gates.
If any of this matches a problem on your line, the fastest way to find out what is possible is a free discovery call followed, where it makes sense, by a feasibility study of two to ten days.