All work

Shipping calculator and tracking: one application for all the company websites

Two separate applications embedded into the pages. They take their data from the accounting system, so they calculate from real tariffs rather than from a table somebody updated last year.

Context

The company has three websites — international shipping, package forwarding and the corporate one — and one accounting system behind them that the sites take tariffs, statuses and requests from.

The job of the interactive part: the calculator and the tracking should work from real tariffs, right on the page.

What was built

Shipping calculator. Calculation by country, city, postcode, weight and dimensions. Scenarios for individuals and for person-to-person shipments, comparison of delivery methods, address suggestions, long lists that do not slow down.

Parcel tracking. By number, with the history of statuses.

Both applications live apart from the websites and are released on their own schedule, but they look like part of the page and take the language and currency from it.

What it looks like

trtexpress.com
The shipping calculator on the international shipping website: a separate application inside the page that takes the language and currency from it
The shipping calculator on the international shipping website: a separate application inside the page that takes the language and currency from it, mobile version
The shipping calculator on the international shipping website: a separate application inside the page that takes the language and currency from it

How it is built

How the three websites, the widgets, the client area and the shipment management system are connectedInternational shipping sitepage builder, 34 blocks · 30+ countriesParcel forwarding site1000+ item catalogue · storesCorporate site44 blocks · 10 form scenarios · LinkedInShipping calculator and trackingone codebase for every site · attached by settings · own releasesClient areaone codebase, two servicesShipment management systemrates · tracking · invoices · processes described in settings, changed without a releaseDatabase and file storagePostgreSQL · files via temporary linksHow the three websites, the widgets, the client area and the shipment management system are connectedInternational shipping sitepage builder, 34 blocks · 30+ countriesParcel forwarding site1000+ item catalogue · storesCorporate site44 blocks · 10 form scenarios · LinkedInShipping calculator and trackingone codebase for every siteattached by settings · own releasesClient areaone codebase, two servicesShipment management systemrates · tracking · invoicesprocesses described in settings, changedwithout a releaseDatabase and file storagePostgreSQL · files via temporary links

Why this way — the calculator as a separate application rather than part of the site

The obvious solution is to build the calculator into the site: one repository, one build, one deploy. I did it differently: two separate applications with their own release.

The calculator is not needed by one site. It lives on the international shipping site and on the forwarding service, and their styling differs. Inside the site that would have meant a copy of the code on each of them and three places to fix the same bug.

The price is honest: two deploys instead of one, and the widget does not know which site it sits on — the site passes it the language and currency through settings. In exchange, a tariff change ships once and appears everywhere, and updating the calculator does not require updating the site.

A calculator like this cannot be built on a site builder at all. That is exactly what people come to me for.

Other case studies

Case studies and personal projects