I didn't build SecondRoute.
At least, not in the way you might expect.
SecondRoute is a product I designed on paper - a proposed system for handling a part of the reverse logistics process. There is no production software behind it, no working backend, and no warehouse running it somewhere.
And that's intentional.
I had a limited amount of time to understand a problem I wasn't deeply familiar with, figure out where the actual opportunity was, design a system around it, and then present and defend that system in front of judges.
Two days later, SecondRoute made it to the final round.
This is how that happened.
Starting with a problem I didn't fully understand
The first challenge wasn't designing the interface.
It was understanding what I was actually designing.
Reverse logistics sounds simple until you start following what happens after a product is returned.
A product comes back. Then what?
Depending on its condition, reason for return, location, value, and other factors, it might be restocked, repaired, refurbished, recycled, liquidated, or handled in another way.
The more I looked at the process, the less it felt like a simple "returns management" problem.
It was a systems problem.
And I had very little time to understand it.
I had two days
This wasn't one of those projects where I could spend weeks interviewing users, running multiple research rounds, testing prototypes, and gradually arriving at a solution.
I had to make decisions quickly.
So instead of trying to understand every part of reverse logistics, I narrowed the scope.
I asked:
"Where can a digital product actually help?"
That question became more important than trying to design the entire reverse logistics ecosystem.
From research to a system
Once I had a clearer picture of the process, I started mapping the different stages and decisions involved.
The important realization was that a returned product isn't just another package moving backwards.
Its next destination depends on information about the product.
That meant SecondRoute needed to be more than a dashboard showing where things were.
It needed to help make sense of what should happen next.
That became the foundation of the product.
The part that didn't work
One of the hardest parts was deciding what not to build.
There is always a temptation, especially when you're designing a complex system, to keep adding features.
Tracking.
Analytics.
Routing.
Inventory.
Condition assessment.
Notifications.
Reports.
The system can quickly become everything.
But with two days, that would have been a mistake.
I had to keep asking myself:
"What is the smallest system that can communicate the idea properly?"
That question helped me cut things down.
Designing SecondRoute
From there, I started turning the process into an actual product.
I worked through the information architecture, the different users and their needs, the decisions the system needed to support, and eventually the interface.
A lot of the work happened away from the screen.
Paper.
Flows.
Boxes.
Arrows.
Questions.
Then screens.
The final product was never meant to claim that I had solved reverse logistics.
It was a representation of how the system could work.
And that distinction matters.
Then came the presentation
After two days of research and design, I had to present the system offline.
This was probably the most useful part of the entire project.
Because presenting a design to yourself is easy.
Presenting it to judges is different.
They don't see the hours you spent figuring things out.
They see the final system and start asking:
Why this?
Why not something else?
Who actually uses this?
What happens in this situation?
What happens if your assumption is wrong?
And suddenly every shortcut you took during the design process becomes visible.
I had to defend the decisions I had made, explain the boundaries of the product, and be honest about what SecondRoute did and didn't solve.
And somehow, it was enough to get through to the final round.
What I would do differently
If I were actually building SecondRoute, the next step wouldn't be writing more UI.
It would be getting out of Figma.
The product would need practical validation with the people and operations involved in reverse logistics.
Some of the assumptions I made in two days would need to be challenged.
Some flows would probably change completely.
Some features I thought were important might turn out to be irrelevant.
And that's exactly why I stopped at the paper-product stage.
I don't want to pretend a prototype is a validated operational system.
SecondRoute was an exploration.
A way to understand a difficult problem, turn that understanding into a proposed system, and then put the thinking under pressure.
For me, that was the real project.
Not building another polished interface.
"Understanding whether I could take an unfamiliar problem, make sense of it quickly, and defend a solution when someone challenged it."