Why dispatch always looks deceptively simple
The visible parts of dispatch fit on one whiteboard. Take an order, assign a driver, track the parcel, confirm the drop. Twelve user stories, maybe twenty.
The invisible parts of dispatch are why every vendor in the space has dozens or hundreds of engineers and is still adding features. Geocoding edge cases. Time-window math. Driver-app reliability under bad signal. Webhook reconciliation when third-party APIs misbehave. Print-server integration. Audit trails. Proof retention. Permissions. Multi-company tenancy. The first three months of building are exciting. The next eighteen months are where the cost lives.
Question 1: How many of your engineers know logistics?
Building dispatch is a domain problem first, an engineering problem second. The teams that ship good logistics software have at least one person who has spent meaningful time in a real courier operation. Without that, the team will reinvent the same five mistakes every existing vendor reinvented in their first year.
Be honest with yourself. Is logistics one of the three things your engineering team understands deeply? If logistics does not make that list, the build path costs a lot more than your sprint estimate suggests.
Question 2: What is the real cost of feature number two?
The first feature is always the cheapest. “Assign a driver” is a couple of weeks. The trouble is that nobody runs a courier operation on one feature.
Add proof of delivery. Now you need image capture, signature capture, secure storage, retention rules, and an admin surface for retrieving them.
Add tracking. Now you need a public tracking page, webhooks for the e-commerce side, throttling, abuse protection, and accurate ETAs.
Add billing. Now you need parcel rating, invoicing, payment recording, payout reconciliation, and integrations with the accounting system the finance team already uses.
The pattern repeats. Every feature you cannot ignore once you actually run on the system multiplies the build estimate.
Question 3: What happens when a driver phone dies?
Buying a vendor with a battle-tested driver app is essentially buying years of edge-case fixes you do not see on the marketing site. Battery drain on long shifts. Background location reliability across Android OEMs. Offline capture that survives a force-close. Push-notification fan-out under load.
If you build, this work is in your future. The roadmap rarely accounts for it because nobody on the planning side has been the support engineer at 21:00 on a Saturday explaining to a driver why their last six deliveries did not sync.
Question 4: Can you replace this in two years?
The cheapest moment to switch dispatch software is before launch. The next-cheapest moment is never.
If you build in-house and it does not work out, you will pay for the build, pay for the rebuild, and absorb the operational chaos in between. If you buy and the vendor disappoints, you can renegotiate, integrate against a different vendor, or migrate. There is a real escape hatch. With a custom build, the escape hatch is “rebuild it again, but better this time”.
Question 5: Is dispatch your moat?
This is the only question that genuinely justifies a build. If your business is differentiated by the dispatch logic itself, build it. If you are a same-day operator with a unique routing approach that no off-the-shelf vendor will support, build it.
If your moat lives elsewhere — customer service, route density, brand, integration depth with a specific shipper — dispatch is plumbing. Plumbing is what you buy.
What an honest “buy” looks like
Honest buying is not “pick the vendor with the most features”. It is:
- Match the vendor's product shape to your operational shape (same-day vs scheduled, owner-operator vs sub-contracted, local SA vs global enterprise).
- Align the vendor's roadmap with your next eighteen months, not their last eighteen.
- Look for honest volume pricing even when the rate card is not on a public page.
- Look for honest scope on the vendor site (no “100% uptime” badges, no fabricated integrations, no claims of features that are still on a roadmap).
CouriB sits on the courier-software side of this question. The features page describes what the platform actually supports today, and the compare page keeps comparison criteria evidence-safe rather than running attack copy on competitors. The pricing page is honest about being contact-led for now, because public plan amounts that are not signed off help nobody.
Build, buy, or hybrid, the five questions above are worth answering before the first commit lands.