The build vs buy question for EV routing comes up at a predictable moment: a fleet software team realises their platform lacks EV routing capability, starts scoping what it would take to build, and either integrates an API or begins an internal project. The teams that build often discover, 18 months in, that they have a working demo and a long way to go.
Here is what building EV routing from scratch actually requires.
The vehicle consumption database is the first and most underestimated component. EV routing is only as good as the consumption models underlying it. A consumption model for a specific vehicle, the Mercedes eSprinter 55 kWh, for example, is not a range figure from the spec sheet. It is a curve describing energy use per kilometre at different speeds, gradients, temperatures, and loads, validated against real driving data. Building this for the 50 to 100 EV models most commonly used in European commercial fleets requires either a significant data collection programme or licensing from a data provider. Reaching the quality level required for reliable commercial fleet routing (not demo-quality, production-quality) takes 12 to 18 months.
The charging station database is the second component. Station location, connector type, charge speed, network access requirements, and availability status — maintained continuously as the network evolves. Stations open, close, change power outputs, merge networks, and fault. A database that is two weeks out of date produces routing recommendations that fail in the field. Maintaining this at production quality is ongoing operational work, not a one-time build.
The routing algorithm is the third component. For single-trip routing, the energy-constraint logic is manageable. For multi-stop routing, optimising a delivery sequence while treating battery state as a constraint across the entire sequence, the algorithm complexity increases significantly. Edge cases accumulate: what happens when a planned station is unavailable? How does partial charging interact with the stop sequence optimisation? How does the algorithm handle the interaction between cold-weather charging curves and stop duration estimates? Building this to production robustness requires specialised routing engineering expertise.
The case for building exists when a team has specific requirements that no available API meets — proprietary vehicle models, unique routing constraints, or integration requirements that API-based solutions cannot accommodate. These cases exist. They are the minority.
For most fleet software teams, the honest comparison looks like this: 12 to 18 months and significant engineering resource to reach production quality, versus weeks to integrate and go live with a quality that would take years to replicate internally. The integration cost, API calls at production scale, is a fraction of the engineering cost of the build. The vehicle database, station database, and algorithm updates are maintained by the provider, not by the internal team.
Chargetrip's API is designed for this integration pattern: a GraphQL interface, well-documented, with a sandbox environment for testing and clear SLAs for production. Integration partners use it as the routing infrastructure layer underneath their fleet management products, delivering EV routing to their customers without building or maintaining the underlying capability.
See how the API integration works or explore the developer documentation.
