Every few years an organisation with capable developers concludes that the commercial products do not fit and it would be cheaper to build. Sometimes that is correct. Usually the initial build is the smallest part of the cost.
What building actually commits you to
The visible cost is the first version. The commitment is:
- Ongoing development as the business changes
- Mobile application maintenance across operating system versions and device changes
- Security patching and vulnerability response, indefinitely
- Infrastructure operation, monitoring and on-call
- Map and road network data licensing, which is a recurring cost with real terms
- Routing engine maintenance, if you build rather than embed one
- Support for your own users
- Documentation and knowledge transfer as staff change
- Regulatory changes — hours rules, e-invoicing mandates, data protection
The mobile application is the trap. A driver app must work offline, sync reliably, handle camera and storage, survive operating system upgrades and run on devices that change every three years. That is a permanent engineering commitment, not a project.
Industry experience across software generally is that maintenance over a system's life substantially exceeds the initial build cost.
When building is defensible
- Your routing problem is genuinely unusual and no commercial product expresses it — unconventional constraints, an unusual optimisation objective, a domain nobody serves.
- The capability is a competitive differentiator, not a commodity. If your routing algorithm is why customers choose you, own it.
- You already have a capable, stable engineering team with capacity, not a team you would need to hire.
- Integration with a heavily customised core system makes commercial products impractical.
- Scale makes licence costs genuinely prohibitive relative to a build — though this threshold is higher than most organisations assume.
When buying is clearly right
- Your requirements are broadly standard, even if they feel special to you
- You have no permanent engineering capability
- Time to value matters — a commercial product is live in months, a build in years
- Compliance features (hours rules, tachograph analysis, e-invoicing) would need continuous regulatory tracking
- The mobile application is central to the work
- You want somebody accountable when it fails at 05:00
The hybrid approaches
Most organisations that "build" should actually assemble.
Embed an optimisation engine. Open-source and commercial routing libraries handle the hard mathematics. Build the workflow, the interface and the integration around them. This captures the customisation benefit without owning the solver.
Buy the mobile app, build the back office. Or the reverse. Several vendors offer driver applications with APIs, letting you keep the operational logic in your own systems.
Buy the platform, build the analytics. Vendor products for operations, your own data warehouse and BI for analysis. Extremely common and usually the right split.
Buy and extend through the API. A commercial platform with a good API, extended with your own services for the parts that are distinctive. This is the most common successful pattern.
If you build
- Staff it permanently. A team that disperses after launch leaves an unmaintainable system.
- Treat it as a product, with a roadmap, a backlog and an owner.
- Document architecture and decisions as if the current team will leave, because they will.
- Use standard components — established routing libraries, mapping providers, cloud services. Do not write your own solver.
- Plan for the mobile lifecycle explicitly, with a device and operating system strategy.
- Budget the ongoing cost honestly and review it against commercial alternatives every two years.
Frequently asked questions
How much does it cost to build route planning software?
Enough that the honest answer is: substantially more than the first estimate, and the initial build is a minority of the lifetime cost. If the comparison is close on the build estimate alone, buying is almost certainly cheaper once maintenance is included.
Can we use open-source routing engines?
Yes, and mature options exist that are entirely capable for many problems. They solve the mathematics; you still own the data model, the interface, the mobile application, the integrations and the operations — which is where most of the cost lives.
What if no vendor fits our requirements?
Re-examine the requirements first; genuinely unserved needs are rarer than they feel during evaluation. If the gap is real, consider a commercial platform extended through its API rather than a full build — it is usually the better trade.
How do we decide?
Model both over ten years including maintenance, staffing, infrastructure and opportunity cost. Then ask whether this capability is a differentiator or a commodity for your business. Commodities should be bought.
What is the most common regret?
Building a mobile driver application. Teams consistently underestimate offline synchronisation, device fragmentation, operating system churn and the ongoing support burden, and it is the component most readily available as a commercial product.
