Designing a Route-Matching Delivery Marketplace: From Problem to MVP

A product design case study: how I approached a delivery app built around people who are already traveling, from the core idea and user flows to the matching logic, trust model and MVP architecture.

At a glance

• Project type: Product concept and MVP design
• My role: Product thinking, UX flows, matching logic, system design
• Market: Dhaka, Bangladesh, as a pilot city
• Proposed stack: Next.js, PostgreSQL, notification and storage services
• Status: Concept and MVP plan, ready for prototyping and a pilot

The problem

Most delivery apps start from the same assumption. Someone has a parcel, they request a delivery, and a courier sends a rider to collect it.

In that model, the rider's whole journey exists only for the parcel. Sending something from Demra to Mirpur means a rider travels to Demra, picks it up, then rides to Mirpur.

But on any given day, people are already traveling from Demra to Mirpur. That raised a simple question:

What if the parcel could go with someone who is already making the trip?

That question turned a courier request into a different kind of product: a route-matching marketplace.

The core idea

The platform connects two groups of people:

• Senders have a parcel and need it moved between two places.
• Travelers are already going from one area to another and are willing to carry a parcel along the way.

The platform does not own the transport. It is the matching layer between an existing journey and an existing need.

Designing around the route

Traditional delivery apps open with a pickup address. This product opens with a route.

That one change shapes every screen. The route becomes the central object in the app, and the interface is designed to show movement rather than forms. A rider's home screen might look like this:

YOUR ROUTE

● Demra
│  12 km
● Mirpur

3 compatible parcels

The sender experience

The sender flow is kept short, because every extra field costs completions on mobile.

1. Origin. Where is the parcel?
2. Destination. Where should it go?
3. Parcel details. Type, approximate size, weight, recipient and contact details. Nothing more than the trip needs.
4. Find riders. The app lists riders on a compatible route, showing only what matters for the decision: the route, departure time and estimated arrival.
5. Request and confirm.

The rider experience

The rider flow is the mirror image. They set where they are traveling from and to, then switch on Accept parcel requests for that route. From that moment, they show up for matching senders.

1. Set my route
2. Turn on parcel requests
3. Browse compatible requests
4. Accept a parcel
5. Pick up
6. Deliver

The marketplace loop

Matches can start from either side. A sender posts a request and the platform finds riders on the route, or a rider announces a route and the platform surfaces parcels going the same way. Either way, the match ends in the same sequence: the rider accepts, picks up, travels and confirms delivery.

The matching problem

Matching is the most interesting technical problem, because routes rarely line up exactly. A rider going from Jatrabari to Mirpur partly overlaps a parcel going from Demra to Mirpur.

A mature matching system would weigh:

• Origin and destination proximity
• Route overlap
• Departure time and estimated arrival
• Parcel size against rider capacity

Combined, those become a match score:

Route fit + Time fit + Capacity fit + Pickup proximity + Drop-off proximity
                                ↓
                           Match score

For the MVP, I would deliberately not build this. The first version can match on five simple attributes: origin area, destination area, departure window, parcel size and rider availability. A smarter algorithm is worth building only once real usage data shows where the simple version fails.

The real risk: marketplace liquidity

A marketplace can work perfectly as software and still fail. If a sender searches and finds no riders, the product feels useless. If a rider announces a route and gets no requests, it feels useless to them too. This is the classic chicken-and-egg problem of two-sided marketplaces.

The answer is density, not coverage. Instead of launching across Bangladesh, the pilot would focus on a cluster of high-volume Dhaka areas:

• Demra
• Mirpur
• Uttara
• Jatrabari
• Mohammadpur

Enough senders and riders on a few routes beat thin coverage of the whole country.

Trust is a core feature, not an add-on

A stranger is carrying someone else's parcel, so trust has to be designed in from day one. The MVP needs:

• Phone verification and user identity
• Rider profiles
• Clear parcel details
• Delivery confirmation
• Transaction history
• Reporting and support

The goal is for both sides to feel that the other is accountable.

Delivery confirmation uses a simple code. The recipient receives a four-digit code, shares it with the rider at handover, and the rider enters it to complete the delivery. The exact method can change later; what matters is a clear, verifiable handover.

The order state machine

Every delivery moves through a fixed set of states, which keeps the backend predictable and easy to reason about:

REQUESTED → MATCHED → ACCEPTED → PICKED_UP → IN_TRANSIT → DELIVERED

Cancellations are handled as separate states, so they never muddy the main flow.

MVP architecture

The first version does not need microservices. One well-structured application on a relational database is enough to validate the idea.

                 Mobile / Web
                      │
                 Next.js app
                      │
       ┌──────────────┼──────────────┐
      Auth          Routes         Orders
       └──────────────┼──────────────┘
                  PostgreSQL
                      │
          ┌───────────┴───────────┐
    Notifications              Storage

Core data model

User      id, name, phone, role
Route     origin, destination, departureTime, status
Delivery  sender, recipient, origin, destination, parcelSize, status
Match     route, delivery, score, status

The schema is a starting point and would change as the product is tested.

What I would not build first

A common MVP mistake is trying to solve everything at once. I would leave out:

• AI route prediction
• Nationwide coverage
• Advanced pricing optimization
• Loyalty programs
• Complex user roles and enterprise dashboards
• Sophisticated analytics

The first version only needs to answer one question:

Can people reliably match a parcel with someone already traveling the same way?

If the answer is yes, there is something worth expanding.

Business model

Revenue options include a transaction fee, a service fee, a percentage of the delivery price, or optional premium services. The right model should be chosen by testing against real user behavior and operating costs.

The marketplace only works if the unit economics work:

Delivery value − Platform cost − Payment cost − Support cost = Contribution

From MVP to platform

If the pilot proves the model, the product can grow in layers, each one added only after the last is validated:

1. Route matching
2. Dynamic pricing
3. Better geographic matching
4. Recurring routes
5. Business accounts
6. Merchant integrations
7. Logistics APIs

Key takeaways

• Question the default workflow. Traditional delivery assumes someone must be assigned to carry a parcel. Asking "Is someone already going there?" leads to a completely different product.
• The hard part is not the app. It is building enough trust, route density and liquidity for the marketplace to feel useful on day one.
• Start narrow. One problem, one cluster of routes, one simple matching rule. Learn from real users, then make the platform smarter.