We Just launched v1.0 of Hikyaku!

I used to keep my run sheet on a clipboard wedged against the steering wheel. Stops ticked off in ballpoint pen, signatures scrawled in the margin, I have all sorts of fuel receipts stuffed in the door pocket or even my pants pocket! I knew exactly how my day was going. However, nobody at the depot did, not until the paper came in that evening and someone typed it into a spreadsheet. When a customer rang at two in the afternoon to ask where their parcel was, the honest answer was a shrug.

I started Hikyaku to get rid of that shrug. Today I released v1.0 of Hikyaku.

飛脚

The word names the couriers of Edo-period Japan. They ran mail and small freight along the Tōkaidō between Edo and Kyoto, about 500 kilometres, and the fastest services covered it in three or four days on foot.

No one ran 500 kilometres. They ran in relays. A courier took his stage between two post stations, handed the box to the next courier, and turned back. The speed never came from any one runner being fast. It came from the handoff being reliable: the box changed hands at a known place, at a known time, to someone who was already waiting for it.

That is still where delivery is won and lost, and it is still the part nobody buys software for.

Delivery breaks at the handoffs

Four parties touch a parcel. The client who booked it, the dispatcher who plans the day, the driver who carries it, and the recipient waiting at the door. Each of those is a handoff and in most operations each one runs on different software, or on none.

The client emails a spreadsheet. The dispatcher retypes it into a planning tool. The driver gets a photo of a printed sheet over WhatsApp (I know, because that driver used to be me). The recipient gets nothing and rings the office, where someone rings the driver, who is halfway up a stairwell and doesn't pick up. Four handoffs, four places for the parcel's state to go missing, and a depot that spends the evening reconstructing the day from paper.

Buying a separate tool for each handoff moves the seams rather than closing them. Now the state lives in four systems that disagree, and someone still has to reconcile them.

Hikyaku covers all four in one system: a dispatcher dashboard, a driver app, a client portal, and a public tracking page for the recipient. One data model underneath all of it. A driver marks a stop delivered on their phone and the dispatcher's map, the client's order view and the recipient's tracking link all know within seconds. Nothing gets retyped, because nothing was ever in two places.

Why it is open source

Delivery runs on margins that survive on the difference between a route that finishes at four and one that finishes at six.

When I built Hikyaku, I went looking for what the incumbents charge. eLogii charges somewhere around $1,500 to $3,000 a month. Bringg doesn't publish a number at all. The cost is nearly always per-driver or per-task, which means the invoice grows with the exact thing that earns the operator money. When the organisation add five vans, you pay more for software that did not change.

Hikyaku charges per route. Each organisation gets a set number of routes included every month, and only pays a small fee once they go over. There's also a Personal tier for small and medium operators that stays free, although it trades away a few features, it's never going to punish you for growing your fleet.

Self-hosting Hikyaku costs what your server costs.

The second reason matters more the longer you run. Your route history, your customer addresses, your drivers' movements and your proof-of-delivery archive are the operation. On a closed platform they sit in someone else's database under someone else's retention policy, and the day you want to leave is the day you find out what they are worth. Hikyaku is AGPL and GPL.

What "operating system" is doing in the tagline

I use it to mean the layer everything else settles against. The clearest example in 1.0 is proof of delivery, which sounds like a small feature until you look at how most fleets actually handle it.

Proof of delivery usually means a signature captured on a company-issued handheld such as a PDA bought and managed just for this or on paper that gets filed away and rarely looked at again. Either way, the org has paid for a fleet of single purpose devices and someone still has to match a signature to a stop, that stop to an order and that order to a customer asking where their confirmation is.

But the dispatch system already knows which driver was at which stop, which run and at what time, since it was the dispatch that assigned the run. So it should be the thing that files the proof on whatever device the driver already has in their pocket.

With Hikyaku, a driver takes the photo or hands over their own phone for a signature, and it lands already attached to the stop, the order, the driver and the timestamp because the system that assigned the run is the system that is watching it happen. It shows up on the dispatcher's map immediately, on the client's order view, and on the recipient's tracking page, with nothing to rename, upload, or match up afterwards. No PDAs to buy, provision, or replace when one goes missing.

Nothing to key in. No photos to hunt down, no "which stop was this again" at month's end.

Where Hikyaku is heading

The driver app is Kotlin Multiplatform and only ships on Android and iOS is the next target. n8n was the first plugin and I would like it to be one of many, which is what the OpenAPI spec is for. I want a genuine migration path for teams coming off Fleetbase rather than a sales conversation about one.

The repositories are public at github.com/HikyakuOrg and self-hosting instructions are in there. If you run vans and something above is wrong about how your day actually works, open an issue and tell me where. I would love to hear it from a depot.