Real-time integration for a recycling operator's AI contamination detection
We connected an on-truck contamination-detection platform to a national waste operator's operational systems. Built, tested and load-proven in under four weeks.
| Item | Result | Notes |
|---|---|---|
| Delivery time | Under 4 weeks | 19 working days from kick-off to a live, load-proven service, at a fixed scope and fixed price |
| Automated tests | 300+ | passing continuously throughout the build |
| Scale headroom | 17x | 5 requests a second sustained, against an expected busy-hour peak of about 1,000 reports an hour - measured by the detection provider, not by us |
| Weekly export | 1.1M | records delivered to the operator's systems every week |
The client: a national waste and recycling operator
A national waste and recycling operator, upgrading the technology its recycling trucks use to spot contaminated recycling bins. Working with its on-truck detection provider, the operator was moving from an older depot-and-WiFi setup to a modern, 4G-connected, cloud-based detection platform.
The challenge: two-way data between trucks and operational systems
The new platform could not work on its own. Photos and detection data from the trucks had to reach the operator's existing systems. At the same time, the live vehicle and collection data the detection depends on had to come back the other way. That integration layer is what the operator came to us to build.
What we built: one integration service, four connected flows
A single integration service handling four connected flows:
- Contamination capture: receives the photos and detection data a truck sends when it flags a contaminated bin, stores the images in the operator's systems, and records each event against the right collection.
- Collection lookups: gives the detection platform the live list of bin lifts for each residential truck, so every photo is matched to the correct bin and household.
- Vehicle lookups: tells the platform which trucks are fitted with detection equipment, and of what type.
- Weekly data export: an automated job that compiles and delivers a weekly file of around 1.1 million records, linking households to their bins.
How we built it: Azure, infrastructure as code and continuous testing
- Built on Microsoft Azure. Every server and setting is written down as code rather than clicked together by hand, so the service can be rebuilt from scratch, checked like any other change, and never depends on one person remembering what they did.
- Security from the start. Nothing reaches the service without proving who it is, and personal references are stored as a one-way fingerprint rather than as the reference itself - so they cannot be read back, by us or by anyone else. The build was reviewed for security before it went live.
- Over 300 automated checks run on every change, so a break shows up before release rather than in front of the public. Live monitoring watches it afterwards and alerts our team first if anything looks wrong.
The results: live in under four weeks, tested to 17 times its busiest hour
Delivered to a fixed scope and fixed price, on budget and on schedule.
The load testing was run by the detection provider connecting to the service, not by us. Ten runs across about 90 minutes put 3,480 requests through it with zero application errors, sustaining 5 requests a second - roughly 18,000 an hour against an expected busy-hour peak of about 1,000 contamination reports. We publish that as 17x rather than 18x, to stay on the conservative side of two approximate figures. Response times held inside our three-second target at realistic volumes.
A clean example of what we do: connecting a modern platform to the operational systems a complex business already runs on, at a fixed scope and fixed price, in under four weeks.
Questions this page raises
How long did it actually take?
Nineteen working days from kick-off to live, which is where the "under four weeks" figure comes from. That was a relatively simple installation at a fixed scope and fixed price, so treat it as what this project took rather than as what any project takes.
Who else was involved?
A third party. The detection platform belongs to a supplier the operator uses, and it had to connect to what we built, so we dealt with that supplier directly as well as with the operator. They also ran the load testing.
See all four case studies, or read making releases boring at a high-street retailer, rolling out a legal requirement to 72,000 households and simplifying a billing structure.