ATS — E-waste compliance app

Summary

ATS (Advanced Tech Solutions) wanted to rebuild and modernise an existing app used by e-waste recyclers to log intake for regulatory compliance — aiming for scalability and end-to-end ownership of the product. There was no need for them to produce complex documentation before we could start: I worked from a story-level explanation of what they needed — problem, people, and constraints. I led discovery, scoping, and prototype delivery — taking that into aligned scope and a working demo in weeks.

The Problem

New South African legislation (EPR — Extended Producer Responsibility) requires electronics producers and importers to prove their e-waste was recycled, or face fines. The existing process was broken:

• Recyclers logged intake in Excel or paper
• Data was siloed at the recycler level
• Producers had no way to pull usable compliance reports

The client had an older app in place but wanted to rebuild and modernise it for scalability, clearer ownership of the product end to end, and a foundation that could grow with regulation and demand — not a one-off patch. They were not expected to deliver a detailed specification pack before the rebuild could start. We began from what they could explain in story form — what was broken, for whom, and under what constraints — and used structured discovery to surface scope, who the users were, and a timeline everyone could agree on.

What I Did

Discovery

The client had multiple user groups with different needs — recyclers logging intake in the field, producers pulling compliance reports, administrators managing the system. Without surfacing that early, scope would have been built around one audience and broken for the others. Discovery clarified who the product actually had to serve, where the riskiest assumptions sat (adoption and reporting), and what the end-to-end workflow looked like against regulatory reality — so the gaps showed up before build began, not during it.

Scoping

Before touching screens or a backlog, I mapped how the main parts of the domain connected. The decision to do this first — rather than jumping to features — is what kept the first release small enough to ship. Hidden dependencies that typically surface mid-build showed up early, when they were cheap to resolve.

Prototype

A clickable prototype was one output of the engagement. The goal was not to ship production code early, but to validate the core workflow with stakeholders and people in field roles before major backend investment — so decisions rested on something tangible, not only slides. It also helped align the group on what “good” looked like on mobile in low-connectivity conditions and test whether the riskiest adoption assumptions held when the flow was exercised end to end.

Outcome

• Aligned on MVP scope, timeline, and engagement terms
• Discovery surfaced the riskiest assumptions early — before they became expensive to unwind in build
• Prototype delivered in weeks as a proof point for stakeholder alignment before committing to full backend build
• Clear path from aligned scope toward implementation

What I Brought

• Preventing expensive surprises: Structured the work so the riskiest unknowns surfaced in discovery — before they became costly to unwind in build
• Designing for the actual job: Navigation built around one-handed, low-connectivity field use — not a desktop workflow forced onto mobile
• Speed without shortcuts: Delivered aligned scope and a working prototype in weeks — fast enough to be useful, rigorous enough to build from

Engagement covered

Discovery, scoping, and prototype — from story-level brief to aligned scope and working demo.