At some point, the dispatcher stopped trusting the software. The optimized routes started coming out consistently wrong enough that someone built a spreadsheet to fix them. Then a second spreadsheet. Then a standing Monday morning correction ritual that nobody put on the calendar but everyone attended.

That is The Workaround Stack. It grows one manual override at a time until the tool your team bought to eliminate dispatcher judgment has become entirely dependent on it. By the time a VP of Engineering notices the problem, the stack is usually two years deep and the SaaS contract has another 14 months on it.

The question that follows is should we build our own route optimization software? This guide covers what a custom build actually involves: what drives cost, what drives timeline, and what architectural decisions determine where on that range your project lands.

When the Build Case Actually Holds

SaaS route optimization tools are the right answer for most fleets. If your routes are relatively stable, your constraint set is standard, and your integration requirements are shallow, a SaaS planner will outperform any custom build on time-to-value for years. The build case becomes real under four specific conditions:

‍

If two or more of these conditions are present, the build conversation is worth having seriously.

What You Are Actually Building

A custom route optimization system is six interconnected layers. The complexity of each determines which cost and timeline tier your project lands in.

Layer 1: VRP Solver Core

The foundation is the engine that solves the Vehicle Routing Problem finding optimal stop sequences across your fleet given a defined constraint set. For the vast majority of commercial builds, this is an integration problem. Production-grade open-source solvers handle Capacitated VRP (CVRP) and VRP with Time Windows (VRPTW) at fleet scale without proprietary algorithm development

‍

Solver selection should happen in Week 1 of the build, not Week 6. The choice determines integration approach, constraint flexibility, and whether you need specialist algorithm talent or standard backend engineering.

Layer 2: Constraint Engine

Above the solver sits the constraint encoding layer the translation of your business rules into mathematical parameters the solver can optimize against. This includes time windows, vehicle weight and volume limits, driver qualification matching, customer priority logic, depot sequencing rules, and pickup-and-delivery dependencies. The constraint engine is where your competitive differentiation lives. It is also where most SaaS tools impose their ceiling.

Layer 3: The Static vs. Dynamic Routing Fork

This is the single biggest cost driver in a custom routing build. Static routing plans routes once daily from fixed inputs. Dynamic routing adds a live data pipeline, continuous GPS positions, real-time traffic feeds, and new order arrivals so the solver can re-optimize mid-execution when conditions change.

‍

If your operation runs same-day deliveries, on-demand dispatch, or exception-heavy routes where conditions change after drivers leave the depot, dynamic routing is not optional. It is also where the infrastructure cost compounds the live GPS and traffic pipeline requires active DevOps attention that static builds do not.

Layer 4: Dispatch Management UI

The planner interface where dispatchers review, adjust, and publish routes before or during execution. At minimum: a map view, route-versus-plan comparison, exception flagging, and a one-click re-optimization trigger. For dynamic builds, this layer also handles mid-route exception management and route broadcasting to driver devices.

Layer 5: Driver Mobile App

An iOS and Android application that gives drivers their sequenced stop list, turn-by-turn navigation, proof-of-delivery capture, and real-time route updates. Offline mode is a practical requirement for operations in low-connectivity areas. Driver app maintenance, OS updates, device fragmentation, UX iteration runs 15–20% of build cost annually and is consistently underestimated in initial budgets.

Layer 6: Integration Layer

Bidirectional connectors to your existing TMS, WMS, ERP, telematics platform, and billing system. This layer translates routing decisions into operational reality pulling order data in, pushing completed route data out, and keeping your systems of record synchronized. For US operators, this layer frequently needs to encode Hours of Service (HOS) compliance rules: federal driver hour limits, mandatory rest periods, and state-specific variations. No SaaS routing tool handles HOS encoding at the constraint level. It is a common build requirement that competitors' content does not mention.

What It Actually Costs

Cost is determined primarily by three decisions made in the first four weeks: static or dynamic routing, open-source solver integration versus proprietary algorithm development, and integration depth with existing TMS/WMS systems. The ranges below assume open-source solver integration by far the more common and cost-effective path.

‍

On team composition: one backend engineer with OR-Tools experience handles the solver integration. The rest of the team is backend, mobile, DevOps, and QA standard product engineering, not operations research specialists.

‍Scoping a routing build?

‍Ideas2IT offers a $0 feasibility session constraint mapping, solver recommendation, and timeline estimate included.

‍Book the session →

‍

What This Looks Like in Practice

A regional last-mile delivery operator running 150 drivers across three depots had been on a SaaS routing platform for four years. Their dispatcher override rate had reached 40% of daily routes nearly half of all optimized routes were being manually corrected before dispatch. A secondary spreadsheet system had been built to handle the top 20 customer-specific delivery rules the SaaS tool could not model. Two engineers spent 30% of their time maintaining that workaround infrastructure.

The decision to build custom came when annual SaaS licensing crossed $180K and the business still could not automate its core constraint set. The build used Google OR-Tools as the solver core, took 28 weeks with a six-engineer team, and eliminated the spreadsheet layer entirely. Dispatcher override rate dropped from 40% to under 8% within 90 days of go-live.

The Development Timeline, Phase by Phase

A well-scoped build with an experienced team follows a predictable five-phase sequence. Integration complexity in Phase 4 is the variable most likely to extend the timeline, shallow API connections compress it; bidirectional ERP sync with legacy systems does not.

‍

Total timeline for a Mid-Tier build: 24 to 32 weeks from scoping to pilot. What cannot be compressed is QA on constraint edge cases a routing engine that fails on its 47th constraint combination does not reveal itself until a real fleet is running on it.

How Ideas2IT handles this situation

There are three ways to build custom route optimization software. You can hire in-house and own everything  which works if you have 18 months and the recruiting pipeline to staff an operations research-adjacent engineering team. You can go to a large consulting firm  which works if your budget has room for architecture decks and governance layers before any code ships. Or you can work with a product engineering partner like Ideas2IT who has done this before and embeds directly in your environment.

Most development partners who take on a custom routing build treat the constraint model as a requirements document. It gets written, reviewed, signed off, and handed to the engineering team. By the time a driver hits a constraint combination nobody thought to test  a particular depot sequencing rule colliding with a driver qualification restriction on a time-windowed stop  it surfaces in live pilot.

Two things in how Ideas2IT structures this engagement address that directly.

The first is how the QA layer is built. Most teams enter a routing build with 20 to 40% test coverage on their existing systems. Manual test plans do not scale to the constraint edge cases that routing engines actually fail on. Qadence generates test automation code from the constraint model itself covering functional flows, integration points, and edge cases that a manual plan will miss at volume.

The second is how the engineering team works during the build. Logistics builds are frequently where companies introduce AI coding tools for the first time. Without standardisation, every engineer uses them differently different security postures, different library choices, no shared playbook. Anticlock closes that gap. Rather than each engineer figuring out the right way to use AI-driven development in this specific environment, Anticlock pre-configures it: the tools, the guardrails, the library standards, the enterprise-safe adoption pattern. The productivity gain from AI coding becomes real and team-wide, not concentrated in two engineers who worked it out themselves.

Both ship as part of the engagement structure.

If your dispatcher override rate is above 20% and your SaaS spend has crossed $80K annually, the math on a custom build is probably already in your favor. The question is what it actually takes at your constraint complexity and integration depth. Ideas2IT maps that in a single working session. Just the numbers you need to make the call.
‍

If your dispatcher override rate is above 20% and your SaaS spend has crossed $80K annually, the math on a custom build is probably already in your favor. The question is what it actually takes at your constraint complexity and integration depth. Ideas2IT maps that in a single working session. Just the numbers you need to make the call.

‍‍Book the session →

‍

References

[1]  OptimoRoute public pricing. Per-driver pricing tiers. https://optimoroute.com/pricing/

[2]  UpperInc (2025). Route optimization software pricing comparison. https://upperinc.com/blog/route-optimization-software/

[4]  Gartner / Digital Applied. Supply chain technology trends: route optimization fuel savings. https://www.gartner.com/en/supply-chain

[6]  NextBillion.ai. VRP API documentation: CVRP and VRPTW constraint support. https://nextbillion.ai/docs/

[7]  TwinCore Logistics Engineering. Route optimization constraint FAQ: when SaaS tools fail. https://www.twincore.io/

[8]  Google Maps Platform. Routes API pricing. https://mapsplatform.google.com/pricing/

[9]  HERE Maps (2025). Enterprise routing and traffic data licensing. https://www.here.com/platform/routing

‍