We worked with Tomra on the software platform underpinning the TOMRA 5C Sorting Machine, one of the most advanced optical sorting machines in their food portfolio.
As with much of our work, confidentiality limits how deeply we can discuss implementation details. But the context, constraints, and shape of the problem — and how the work unfolded — are worth sharing, because they reflect the kinds of environments where starting well really matters.
The World TOMRA Operates In
TOMRA builds machines that operate at the intersection of physics, optics, mechanics and software. Their systems are used globally across food, recycling and mining — often in places where failure is expensive, downtime is unacceptable, and support is not a phone call away.
In food processing, TOMRA sorters sit directly on production lines. They make thousands of decisions per second, separating good product from defects and foreign material. Quality standards are unforgiving.
A useful (and interesting) reference point: every McDonald’s french fry is processed through TOMRA sorting technology before it reaches a restaurant, and they have some of the most exacting standards in their industry.
The TOMRA 5C sits at the high end of this world. Publicly, it is positioned as a premium optical sorter, combining advanced cameras, lasers and biometric sensing to detect defects that are invisible to the human eye. It’s used for products like nuts, dried fruit and frozen vegetables — applications where subtle imperfections matter.
This is not consumer software. It is industrial software embedded in physical machines, deployed globally, expected to run continuously, and trusted to make decisions that directly affect food safety and yield.
Constraints That Shape Everything
One of the defining complexities of the 5C platform was where and how it had to run.
Many of these machines operate in remote environments — agricultural facilities, processing plants, and production lines with limited or no internet connectivity. Updates are often delivered physically, sometimes via USB, during planned maintenance windows.
That reality rules out a whole class of assumptions common in modern software:
- No reliance on always-on connectivity
- No cloud-based control plane
- No real-time remote intervention
The software had to be self-contained, resilient, and predictable, capable of running unattended for long periods while still supporting evolution over a long machine lifespan.
Standing on a Lot of History
Another source of complexity wasn’t tooling — it was accumulated knowledge.
TOMRA had decades of learning embedded across previous machines:
behavioural nuances, configuration options, edge cases discovered in the field, and adaptations made for specific products and customers.
The challenge wasn’t replacing something crude. It was bringing an immense amount of existing capability together into a single, coherent platform — without losing the flexibility customers relied on.
This meant supporting:
- Extensive customisation
- Product-specific behaviour
- Regional and regulatory variation
- Hardware differences across deployments
All while making the system understandable, testable and maintainable.
Where Things Were When We Arrived
When we joined, TOMRA had a strong team and deep domain expertise. What they were struggling with wasn’t competence — it was how to begin.
Given the scale of the problem and the cost of mistakes, there had been a lot of careful planning. Multiple architectures had been considered. Dependencies mapped. Edge cases discussed early.
The caution was justified. These machines are expensive to build, difficult to retrofit, and operate in environments where delays can shut down production lines.
But the result was a familiar pattern: a great deal of thinking, and not much movement.
Creating Something to Push Against
On the first day, the priority wasn’t to perfect a design. It was to create something real.
We worked with the team to identify a narrow but representative slice of the system — something small enough to build quickly, but meaningful enough to expose real constraints.
Within the first week, we had the beginnings of the 5C software platform running.
Not a throwaway prototype. The early shape of the real system.
That shift mattered. Once software exists, conversations change. Assumptions can be tested. Trade-offs become visible. Progress becomes measurable.
How the Work Unfolded
From there, the approach stayed consistent.
Close, practical collaboration
We worked directly with TOMRA engineers and domain experts, often pairing live — not just on code, but on understanding machine behaviour, operator workflows, and real-world usage.
This wasn’t about “handing over requirements”. It was shared problem-solving, happening in real time.
Iterative, usable progress
Rather than aiming for completeness, we focused on usable increments — small steps that reduced uncertainty and moved the system forward without locking in premature decisions.
Frequent demonstrations
Regular demos ensured that progress was visible and grounded. They also made it easier to course-correct early, before complexity hardened into constraint.
Focus over noise
As the platform grew, complexity inevitably increased. Part of our role was helping the team distinguish between:
- What genuinely mattered now
- What could wait
- What didn’t need solving at all
That focus kept momentum without cutting corners.
Engineering for Reality
Without going into sensitive detail, the resulting platform reflected a shift away from ad-hoc configuration towards something more deliberate and expressive.
Key characteristics included:
- A structured, governed environment for defining and evolving machine behaviour
- Clear separation of responsibilities within the system to manage complexity
- Support for large configuration sets and variation without fragmentation
- Software designed to live alongside physical machinery for many years
The aim wasn’t novelty. It was clarity, traceability and long-term maintainability — essential when software directly controls physical processes.
A Deadline That Really Mattered
One moment stands out.
A critical delivery milestone coincided with a physical constraint: a time window during which the machine itself had to be moved into place - through an actual doorway created by knocking down (and later rebuilding) a physical wall! Obviously, ensuring timely delivery whilst a factory in a remote part of the world was offline between seasons was critical.
The deadline was met, with software ready, machine installed, and work able to resume.
It was a good reminder that in this world, delivery isn’t abstract. It’s tied to cranes, factory floors and real logistics.
A Company Used to Big Outcomes
TOMRA’s work often sits quietly behind the scenes, but its impact is substantial.
In mining, TOMRA’s sensor-based sorting technology has been used in diamond recovery operations — including the discovery of some of the world’s largest high-value diamonds, where precision detection makes the difference between recovery and loss.
Whether sorting food at scale or separating minerals worth millions, the common thread is the same: software and sensors working together, reliably, in difficult conditions.
In Closing
The TOMRA 5C platform didn’t succeed because the problem was simple. It succeeded because a capable team was able to move past hesitation, focus on what mattered, and let working software guide decisions.
Our contribution was helping create that momentum — cutting through noise, grounding discussions in reality, and turning complexity into something tractable.
It’s a pattern we see often in high-stakes environments. And it’s one we’re always glad to help with.