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
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:
- Fuel — from consumption per 100 km and the diesel price, with a reference price for each of 28 countries.
- Tolls — broken down per country along the route.
- Profit, margin and profit per kilometre — the three figures a dispatcher actually argues about.
- Delivery time in days — derived from the EU 561/2006 driving-time limit rather than from wishful thinking.
- CO₂ — increasingly asked for by European clients.
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.
data.js— reference figures only: diesel prices, tolls and driving restrictions for 28 countries, plus a distance matrix of 43 country pairs. No logic.engine.js— the calculation, written as pure functions that never touch the DOM. It exports itself both to the browser and to Node, so the maths can be run outside a page.app.js— the only file that is allowed to touch the interface. It contains no calculation of its own.
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:
- Polish toll rates — the known error above.
- Fuller driving-time rules. Today the delivery estimate uses the 9-hour daily driving limit. The 45-minute break after 4.5 hours and the daily rest are documented in the code but do not yet affect the result.
- Per-country fuel prices along a route. Prices are held for all 28 countries, but a single price is currently applied to the whole trip.
- Tests. The engine was deliberately written to be testable — pure functions, exported to Node. The tests themselves are not written yet.