Making Supplier Returns Part of the Inbounding Flow

The Problem

At Flink, warehouse operators use an internal app called Hub One App to manage inventory operations.

One recurring issue was handling products that arrived damaged or too close to their expiration date. Reporting these products required workers to finish inbounding, fill out external forms, take photos, and send everything to another team.

It wasn't especially hard, but it was time-consuming, repetitive, and pulled people away from the work they actually needed to focus on.

My Role

I led the technical implementation of a new flow that allowed warehouse operators to report damaged products directly inside the app they were already using.

My work included:

Designing how images would be uploaded and stored
Working with backend engineers on the required APIs
Building a reusable photo upload component for our Design System
Integrating the new flow into the inbounding experience

The Solution

Instead of sending workers to a separate process, we brought everything into the inbounding flow itself.

Now, when a damaged product is detected, operators can:

Take photos directly from their Zebra device
Add the required information
Submit everything without leaving the app

To support this, I built a reusable upload component that handled camera access, image previews, multiple uploads, loading states, and error handling.

One thing I particularly enjoyed in this project was designing the component in a way that wasn't tied to a specific API or workflow. A few months later, another team reused it for a different feature.

Challenges

Even though the feature sounds simple on the surface, there were a few interesting constraints.

The app runs as a PWA on Zebra warehouse devices, so reliability and device compatibility were more important than using fancy browser APIs.

I also had to define how images should be stored, who needed access to them, and how they would fit into the existing backend architecture.

After talking with stakeholders, we discovered that suppliers needed access to the photos, which influenced how we approached storage and image delivery.

Impact

The feature was rolled out across roughly 160 Flink hubs.

For warehouse operators, it removed an extra process that could easily add around 20 minutes of work whenever damaged products had to be reported.

For supplier teams, reports became available immediately, including all the relevant photos and metadata, which reduced the amount of back-and-forth communication with operations teams.

For engineering, the project left us with a reusable upload component that could be leveraged by future features instead of rebuilding the same functionality again.

What I Learned

This project reminded me that the most valuable solutions aren't always the most technically complex ones.

The upload component itself was important, but the real impact came from understanding the operational workflow and removing friction for the people using the product every day.

It's also one of the projects I'm most proud of because it gave me the chance to work across multiple parts of the stack, from frontend architecture and Design System work to API design and storage decisions, and see how those pieces come together to solve a real-world problem.