All projects Own product

FreightIQ

A calculator that tells a haulier whether a trip across Europe will actually make money — after fuel, tolls and the hours a driver is legally allowed to drive.

My role
Idea, design, code
Timeframe
A few weeks
Stack
HTML, CSS, vanilla JS
Status
Live, in development
The FreightIQ calculator interface

Where the problem came from

My family runs a haulage company that works across Ukraine and Europe, so I did not have to research this industry — I grew up next to it. The recurring picture: a dispatcher gets an offer for a trip, and to find out whether it is worth taking, opens a spreadsheet. Fuel is estimated roughly. Tolls are guessed, because every country charges differently. Whether the driver can legally cover the distance in the promised time is worked out in someone's head.

Each of those three answers exists somewhere. None of them is in one place, and none is quick to get. That gap is what FreightIQ closes.

What it actually calculates

You enter the route, the freight rate and your other costs. You get back the numbers that decide whether to take the load:

Routes can be saved and up to three compared side by side, and any result exports to PDF for sending on to a client.

The hard part: tolls

This is where I spent most of the time, and it is worth explaining why, because the difficulty is not technical.

There is no single way Europe charges trucks. Germany charges per kilometre, and the rate depends on the number of axles and the emission class. The Netherlands does not charge per kilometre at all — it uses a time-based Eurovignette. Switzerland charges per tonne-kilometre. Modelling all of that honestly would mean a data set larger than the calculator itself, kept up to date across 28 jurisdictions.

So I made the trade-off explicit instead of hiding it. The reference table holds one averaged rate in €/km per country, with a value of zero for the seven countries where per-kilometre charging does not apply — each one carrying a comment in the data explaining what is used there instead. Assumptions are stated in the file header and in a disclaimer on the page itself.

More importantly, the calculator does not force my numbers on anyone. There are three ways to enter tolls: the total sum for the trip, your own rate in €/km, or the reference figure as a fallback. A dispatcher who knows what Poland really costs them enters that and gets a correct answer regardless of my table.

The lesson I took from this: when a domain resists precise modelling, the honest move is not to fake precision. It is to make the assumption visible and give the user a way around it.

How the code is organised

Around 4,900 lines, no build step — the project opens by double-clicking the file. That constraint shaped the architecture rather than excusing the lack of one.

A few decisions I would repeat on a client project: all dynamic content is built with createElement and textContent rather than innerHTML, and user-supplied links pass through a protocol whitelist, so text typed by a user can never become markup. Input is forgiving — a comma works as a decimal separator, and transit countries are accepted either as ISO codes or as Ukrainian names. The whole interface respects prefers-reduced-motion, and results are announced through an aria-live region so a screen reader hears the recalculated figure.

Checking it against reality

I showed it to the person who runs the haulage company. The verdict: useful — but the toll rates for Poland are not accurate.

That is the most valuable feedback the project has had. A data error of exactly the kind you cannot spot without having worked in the industry, found in minutes by someone who has. Correcting the Polish rates is next in line.

What comes next

The project is still in development, and I would rather list what is missing than pretend it is finished: