I built a live freight-market board out of entirely free public data
A freight forwarder told me visitors read a services page and left. The fix was not a chatbot — it was giving them a reason to come back, assembled from data that costs nothing. Here is the problem, the answer, and how it was actually engineered.
Raj Singh
The client moves containers between Turkey and the UK and US. Their brief was about as blunt as a brief gets: people land on the site, read a services page, and leave. Get them to stay longer, and get them to come back.
The default answer in 2026 is to bolt a chatbot onto the corner of the page. I think that is almost always the wrong move, and it is worth being precise about why.
A chatbot is a better version of the enquiry form. It still asks the visitor to give you something before they have received anything. If someone is not ready to enquire — and on a freight forwarder's site, most people are researching, comparing, or checking whether a rate they have been quoted is sane — then a friendlier way to ask them to enquire does not help. They still leave. You have just spent money making the leaving more polite.
The question worth answering was different: what would make someone in freight open this site on a Tuesday morning when they are not buying anything?
What freight buyers actually stare at
Container pricing is not really a price. It is a set of inputs, and the people who buy freight professionally track those inputs, because they determine whether the number in front of them is reasonable this week.
When a chokepoint clogs, sailings reroute and rates move. When diesel moves, surcharges follow. When a currency pair moves, a quote issued three weeks ago stops meaning what it meant. None of this is secret. It is just scattered across a dozen places, and nobody in a small forwarding business has time to assemble it every morning.
That is the gap. Not information nobody has — information everybody wants and nobody has time to collect.
What went on the board
Four things, on one screen:
Chokepoint transits. Daily vessel counts through the Bosporus, Suez, Bab el-Mandeb and Hormuz, from satellite positioning. Congestion is visible here days before it shows up in a rate.
Port call volumes. Container calls at the loading ports (Turkish terminals like Ambarlı) and the discharge ports (UK, US East Coast). This is the capacity-and-delay signal at both ends of the actual route the customer cares about.
Cost drivers. Diesel, Brent crude, EUR/TRY. The three numbers sitting underneath every fuel surcharge and every currency adjustment on an invoice.
Trade press. A curated headline feed, so the numbers have context rather than sitting there as decoration.
Put together, it answers a question the visitor genuinely has — is the market moving against me right now? — without asking them for anything at all.
Every source is free, and that was a design decision
IMF port data. US EIA fuel prices. ECB reference rates. Public trade publications. No commercial data contract, no API key, no per-call billing, no login wall.
This was not about being cheap. Three things follow from it.
The first is that the tool cannot quietly become a liability. A board built on a paid feed has a monthly cost that grows with traffic, which means the better it works, the more it costs. That is a bad shape for a small business, and it is the reason these things get switched off eighteen months later.
The second is that there is nothing to renegotiate. No contract to renew, no vendor who reprices when they notice you depend on them.
The third is the boring one that matters most: the client can keep it. It runs in their accounts, on their domain, and if I disappear tomorrow it does not stop working. I think this ought to be the default for anything you build for someone else, and it very often is not.
The engineering that follows is unglamorous — fetch on a schedule, cache hard, serve the cache, rate-limit the edge, and degrade to the last good value rather than showing an error when a source is slow. A traffic spike costs nothing because a traffic spike does not reach the sources.
The commercial point is at the bottom
At the end of the board there is a structured pricing request: route, cargo type, specifications.
This is the whole trick, and it is not subtle. By the time somebody reaches that form, they have been reading about their own trade lane for two minutes. They arrive at the request already knowing what they want to ask, and they fill it in properly, because it now feels like the natural next step rather than a toll gate.
Compare that with the same form on a services page. Same fields, same code, completely different act. On the services page you are asking a stranger to identify themselves in exchange for nothing. On the board you are asking someone who has just been given something useful whether they would like the specific version of it.
The enquiry that lands is also better. It has the route and the cargo in it. Someone reading it on the forwarder's side can price it, instead of writing back to ask the two questions every unqualified enquiry forces you to ask.
The pattern, and where it does not apply
I have now built the same shape three times in three unrelated industries — dental treatment, freight, language learning. It generalises further than I expected:
- Find the thing your buyer already checks, or wishes they could check.
- Build that, properly, and give it away with no gate on it.
- Put the specific, structured version of the enquiry at the end.
The honest caveat is that this needs a real informational need underneath it. Freight has one because rates are volatile and inputs are public. Dental work has one because patients cannot tell what they need or what it should cost. If your market has neither — if the buyer already knows exactly what they want and is only comparing price — then a calculator is a distraction and you should compete on the thing they are actually comparing.
What I would do differently
I would have built the enquiry step first. I built the board, liked it, and then attached the capture at the end, which meant the two were designed separately when the whole argument for the thing is that they are one motion. Next time the structured request comes first and the tool gets built backwards from it.
I would also instrument it harder from day one. It is live and I can tell you exactly what it does; I cannot yet tell you what it changed, because it has not been running long enough to have data worth quoting. When it has, I will write that up too — including if the answer is that it made no difference.
Built as part of Gomago, a global trade platform still under construction, for a freight forwarder moving containers between Turkey and the UK and US. I'll link it when it is finished rather than send anyone to a half-built product.