Router

What did you build and how does it address the prompt?

We built Router, an Android overlay that helps delivery drivers decide whether an order is worth taking. When an offer appears in any delivery app, Router shows one clear answer, Take, Maybe, or Skip, with one plain reason. It also shows the driver's current hourly rate and how far the order takes them from home. When a driver has two orders, it tells them which to pick up and deliver first.

The prompt asks for a product that expands who can successfully use a system. Delivery work is open to everyone, but it pays off mainly for drivers who have learned the hidden math behind each offer. Router does that math for them, so new drivers and drivers who find fast number decisions hard can make good choices from their first day.

Target user group, pain points, and how the solution helps

Target users: delivery drivers who face a cognitive barrier when making fast decisions. This includes new and part-time drivers, non-native English speakers, older drivers, and people who find quick, multi-step number decisions difficult, such as people with ADHD, dyscalculia, or anxiety. Router never asks about or diagnoses any condition. It is simply designed to work better for these drivers.

Pain points:

Drivers have only a few seconds to accept or decline an order.
A good decision requires combining pay, gas cost, waiting time, the drive home, and how the day is going.
The apps do not explain how pay is calculated.
Offer screens are dense with numbers and written in English.
A bad order does not look bad in the moment, so drivers often earn less than they think.

How Router helps:

One word, one color, and one reason, readable at a glance
A current hourly rate that includes gas and waiting time
Distance from home, so the unpaid drive back is not a surprise at the end of a shift
A clear pickup and delivery order when the driver has two orders
A short setup before each shift, so every suggestion matches the driver's car, goal, and end time

How did you build it?

We built a working web prototype that simulates the Android overlay on a phone screen. It shows a mock delivery offer with Router's card on top. The prototype uses Next.js, TypeScript, Tailwind CSS, and shadcn/ui.

The decision logic is a separate engine with automated tests. It calculates profit after gas and wear, compares taking an order now with waiting for a better one, adds the cost of driving home near the end of a shift, and checks all six possible stop orders when there are two orders. A Demo Mode walks through the main situations: shift setup, a Take, a Maybe at the end of a shift, a Skip, and two orders at once.

Challenges we ran into

Too much information. Our first version showed many numbers. Each round of feedback, we removed details until the card showed only what a driver needs in a few seconds.
Making the demo clear to viewers. We added a shift setup screen and labeled arrows so viewers understand what each number means.
Platform limits. iOS does not allow apps to draw on top of other apps, so we chose Android.
Safety and trust. We made Router read-only. It never taps for the driver and never logs in to their delivery accounts.

What tools did you use, what issues did you run into, and how did you overcome them?

We used Claude to explore and define the problem, and Perplexity for background research on driver experiences and existing tools. We used Cursor's AI coding agents to plan, build, and test the prototype, along with Next.js, TypeScript, Tailwind CSS, shadcn/ui, and Vitest for testing.

Sharing the demo. A temporary public link expired whenever the server stopped. We exported the prototype as a static website so it can be hosted permanently.
Old versions in browsers. Browsers kept showing older copies after updates, so we turned off page caching.
Keeping the math honest. Every time we changed a scenario, the automated tests confirmed the verdicts were still correct.

What we learned

The hardest design decision was what not to show.
One word and one color can carry a complex decision.
Waiting time changes the value of an order. A weak order can be the right choice after a long wait.
Designing for people who face the biggest barriers made the product simpler for everyone.

How can you implement this further?

Build the native Android app: read the offer screen with on-device text recognition and draw the card with Android's overlay permission.
Add Spanish, voice prompts, and vibration, so drivers can keep their eyes on the road.
Detect completed deliveries automatically, so drivers do not need to tap.
Use the fuel level to warn drivers when an order is longer than their remaining gas allows.
Test with real drivers, comparing speed and decision quality with and without Router.