Solving NP-hard problems with real tools, not reinventing them
The temptation to implement your own optimization algorithm is strong and almost always wrong. When leaning on specialized tools is the correct engineering call.
There's a predictable moment in any project involving route optimization, resource allocation, or task scheduling: someone on the team suggests implementing the algorithm. Dijkstra, A*, a hand-written linear programming solver. The intention is good, it's an interesting problem, and solving it feels like real engineering. The result, almost always, is development time spent rebuilding something that already exists, battle-tested in production for years, at a level of optimization no individual developer is going to reach within a commercial project's available time.
Why intuition is misleading here
The problem of assigning dozens of stops to a fleet of vehicles with capacity constraints and time windows isn't a bigger version of shortest-path-between-two-points. It's a problem in a fundamentally different complexity class (NP-hard), where the solution space grows combinatorially and no known algorithm guarantees the optimal solution in reasonable time at any scale. Classic graph algorithms like Dijkstra solve a related but fundamentally simpler problem: the shortest path between two nodes, not the optimal assignment of multiple stops across multiple vehicles under constraints.
Conflating these two problems is where the mistake originates: the wrong algorithm gets implemented correctly.
The real engineering decision
The question worth asking isn't "can I implement this algorithm?" Almost any engineer with a data structures background can. The question is "does the business value live in the optimization algorithm itself, or in integrating it correctly into the rest of the system?" For the vast majority of products, logistics, scheduling, resource allocation, the answer is the latter. The business doesn't compete on having the world's best routing solver, it competes on having the complete product that uses that solver correctly: clean input data, well-modeled constraints, well-presented results, and a system that reacts to real-time changes.
Specialized, mature tools for this class of problem, vehicle routing solvers, distance-calculation engines over real map data, constraint-programming libraries, have received years of specific optimization for cases an individual developer can't replicate within a sprint's timeframe. Leaning on them isn't giving up on engineering, it's redirecting engineering effort to where the business actually needs it: integration, domain-specific constraint modeling, and the end-user experience.
The risk on the other side
This isn't an argument for never writing your own algorithms. There are legitimate cases, very business-specific constraints that no generic tool models well, volumes that don't justify the operational complexity of an external tool, or licensing restrictions, where building something simpler in-house is the right call. The mistake isn't writing your own algorithm, it's doing so by default, without explicitly weighing the cost of building and maintaining it against the cost of integrating a tool that already solved it.
The lesson
Mature engineering in these cases isn't measured by the ability to implement the algorithm from scratch, it's measured by recognizing when that isn't the problem worth solving. The differentiating skill is knowing how to read a specialized tool's documentation, correctly model the business's constraints as its input, and build the rest of the system around it with the same seriousness you'd give a component you wrote yourself.