VRP app as a Minimum Viable Product

Question

In this post, Geoffrey De Smet and EhsanK pointed out the opportunities of VRP variants (e.g. mixed pick up and deliveries).

If I want to build a Minimum Viable Product (software as a service app). My question is: Which variant to consider (which constraints and objective function)?

The VRP has a lot of applications in different markets. My main concern is to cover as much "markets" as possible without falling in the trap of including a lot of details at the beginning. In other words, I want an incremental deployment approach rather than a "big-bang" approach. Thus I can implement a MVP, try to do some marketing/sales and then listen to customers to add further details. I don't want to spend a lot of time on something that will not make me money.

Answer 1

For what it's worth...

We have an out-of-the-box open source VRP application in Java, yet it always needs to be customized to meet a user's or customer's needs. Although many VRP variants can use the same model, many other variations don't fit the same model. For example, VRP with pickup and deliveries are fundamentally different from CVRP's (with or without timewindows). Just find your niche.

I once believed that if you build a great app, end users will automatically use it. That's naive. Sales/marketing are just as vital as having a great product. Basically, it's a multiplication. If either side is zero, the result is zero. However there's a lot of marketing that can be done without a budget.

There's an annoying Catch 22 in this game: to build a product that can sell, there are 3 things you need to do: talk to users, talk to users and talk to users. But users won't talk to you if you can't show them a demo that looks like it will solve their problem.

Don't let that stop you though :) The road to success is paved with failures. Good luck!

Answer 2

I totally agree with what @Geoffrey De Smet and @Renaud M. said. I only add my two cents here so it hopefully helps you to think about what you're creating:

• You know it already that it's best to start simple for an MVP and then add more features to it. Although I can suggest that the first pass can be CVRP with time windows, there is another important step before this and that's the market you like to target (no holy grail solution. Another MVP is the narrowing down the market IMO)! Think about it. The problem that UPS last-mile delivery needs to solve with tens or hundreds of stops in a day, can be very different from what a mover company does (e.g. think of those movers that drop their trailers for you to partially fill the truck and then they repeat this until the truck is full) or even what Uber eat does! You may put them all in the same category but the difference between the constraints and their planning horizon can totally change how you design your solution. So, first stop, what's the market?
• Now that you know the market, you see that your MVP is totally linked to that market and may no longer be CVRP. You may even realize that in some markets you always have Open VRP (your vehicle/salesman/driver doesn't need to return to the origin after ending service). That, again, changes the solution you design. So, we're back to "what's the market?"
• Since you know the market, one other obvious step is to search how the problems in that market are already solved and what your potential solution can offer that's not in the market. The worst-case scenario is to create something that will cost more and is less sophisticated than the current approach (sophisticated here means closer to the real-life constraints). This may be a step easier said than done. However, as you know there is a balance. You may offer something less sophisticated but much more user-friendly, faster, and cheaper and that can be a selling point.
• If not obvious, when you decide your market, you know the most common type of constraints in that market. But don't fall for some of the simplifying assumptions that you may find in some academic papers. There are pieces that you may not consider as a constraint up-front but they may consume a lot of time for you later. For example, "let's assume that the cost to go from A to B depends on the distance...". Well, ok but are you sure you're solving a problem that this assumption is valid? If you deal with small vans and parcels, I'm afraid this assumption won't make your users very happy.

I'll edit this if more comes to my mind. Good luck and I hope this helps you in your path!