TSP Route Planning

Turning the travelling salesman problem into a tool

Finding the shortest order to visit a set of stops is known as the travelling salesman problem. Solving it exactly is hard, but approximate answers that are good enough for real work arrive in seconds.

Best for: Anyone planning routes, dispatch planning, operations improvement, software selection

Turning the travelling salesman problem into a tool

Current limits and how the app works

How many destinations can I calculate?

Route calculation currently supports 10 destinations on both Free and Pro. The Pro input screen allows 30, but calculations with 11 or more do not complete. Bulk parsing limits of 20/100 lines are separate from the calculation limit.

Is data sent outside my device?

History, notes and photos are stored on your device. Place searches and route calculations send addresses, place information and coordinates to our server, which sends the necessary data to map services. Opening an external map or calendar also passes the selected places or schedule to that service.

How do Pro purchases and trials work?

Purchase Pro inside the iOS or Android app; Web purchases are unavailable. Check the purchase screen for regional prices and eligibility for the 7-day free trial. Cloud sync and team management are not currently provided.

Is the shortest route guaranteed?

Calculate a suggested order using travel times. Set departure and stop durations or fix positions in the order. The shortest route is not guaranteed. Target arrival times trigger late warnings; they do not automatically constrain the route.

Pain Points

Where manual sequencing breaks down

  • ! The number of possible orders explodes as stops are added
  • ! Quality depends on who is planning that day
  • ! People judge by straight-line distance rather than road travel
  • ! Dwell time and preferred arrival times get left out

Solution

What makes it work in practice

  • ✓ Aim for an answer that is good enough, delivered quickly
  • ✓ Judge order by map-service travel-time estimates
  • ✓ Use dwell time in the schedule and preferred arrivals for late warnings, not routing constraints
  • ✓ Fix the starting point so the plan matches how the day actually runs

Workflow

How Go(od)Route applies it

1

Enter stops and planning details

Addresses plus starting point, dwell time and preferred arrival times.

2

Compute the order

An order that works in practice is produced in seconds, judged on travel time.

3

Put it to work

Check the arrival times and hand each leg to your navigation app.

Why It Works

Why not solve it exactly

Go(od)Route focuses on the work before navigation: deciding the order, saving repeat routes, and keeping useful records.

Exact solutions become impractical to compute as stops are added

In the field, getting an answer immediately beats a few minutes of theoretical saving

Traffic and dwell time vary anyway, so extreme precision buys little

FAQ

Frequently Asked Questions

What is the travelling salesman problem?

It asks for the shortest route that visits every location once and returns to the start. As locations are added, the number of possible orders grows so quickly that checking them all stops being practical.

Is an approximate answer good enough?

For most work, yes. Real travel times shift with traffic and visits run long or short. Being able to recalculate the moment something changes is worth more than chasing the last few percent.

Can I fix where the route starts?

Yes, you can set a starting point so the calculation matches how your day actually begins.

Let the app do the ordering

Enter your stops and get a visiting order you can actually use.