Software that moves freight and goods

Tracking and operations platforms, shipper and partner portals, dispatch and booking systems, driver applications, dashboards and AI tooling, built for throughput, uptime and real time visibility. Logistics software has an unforgiving characteristic: it describes physical things that are already moving, so incorrect or stale data has immediate operational cost rather than merely being untidy. We design the data model and the update path around that reality, because a tracking system that is occasionally wrong quickly stops being trusted, and an untrusted system gets replaced by phone calls.

Yes, including transport and warehouse management systems, ERP, and carrier and customs interfaces, so shipments, statuses and documents stay in step without manual re-entry. Carrier integrations are the awkward part in practice: they vary widely in quality, some are modern REST interfaces while others are older formats or scheduled file transfers, and rate limits differ considerably. We build an abstraction over them so adding a carrier later does not mean reworking the platform, and we handle their failures explicitly rather than assuming availability.

Yes. We build route optimisation, demand forecasting, estimated arrival prediction and document processing models on current model stacks including Claude. Document processing is often the fastest return in logistics, because extracting data from delivery notes, invoices and customs paperwork removes genuinely repetitive manual work with a clear before and after. Routing and forecasting deliver more but need reliable historical data to learn from, so we usually check that your data is complete and clean enough before proposing them rather than after.

Yes, and we design for the peak rather than the average because logistics volume is highly seasonal and event driven. That means high throughput ingestion of carrier and telemetry updates, queue backed processing so a surge is absorbed rather than dropped, caching for the read heavy tracking views your customers hit, and infrastructure that scales horizontally. We load test against realistic peak volumes rather than typical traffic, and we design the system to degrade gracefully, since delayed status updates during a spike are far better than an unavailable platform.

You do, completely. You receive clean, documented, well structured code and full ownership of everything we build, held in your own repositories from the first commit rather than transferred at the end. This matters in logistics because these platforms tend to be long lived operational dependencies rather than projects with an end date. You should never be in a position where a commercial disagreement with a supplier threatens your ability to dispatch, and you should be able to change provider without unpicking a dependency on us.

A tracking portal or driver application typically goes live in eight to fourteen weeks. A full transport or warehouse management system runs sixteen to twenty eight weeks depending on complexity and integrations, and we agree the timeline before starting. Carrier and customs integrations usually determine the schedule rather than the interface work, because each depends on another organisation’s access process, sandbox availability and approval timelines. We confirm what is actually available during discovery rather than assuming, since that assumption is the usual cause of slippage.

Cost depends on scope and on which systems and carriers we integrate with. We scope to your goals and budget and send a fixed proposal, usually within 24 hours, so there are no surprises. Integration count is the largest single driver: each additional carrier or customs interface carries real build and ongoing maintenance cost, so we will often suggest starting with the carriers covering most of your volume and adding the long tail once the platform is proven. That keeps the initial investment proportionate to the operational benefit.

Yes. Real time shipment, fleet and order tracking is core to what we build, for your operations team and for your customers, and it reliably reduces where is my order enquiries, which is often the clearest measurable saving in the whole project. The design point that matters is being honest about precision: updates arrive at intervals and estimates are estimates, so an interface implying continuous accuracy generates complaints when reality differs. We show meaningful progress and communicate uncertainty rather than implying precision the data cannot support.

Often yes, though the honest answer is that it depends on your current baseline. Route optimisation, load planning and demand forecasting reduce empty running and improve fill rates, and the gains show up in your own data rather than in a vendor’s case study. The important caveat is that if your routing is currently manual and unoptimised, the first improvements come from basic optimisation rather than from machine learning, and they are cheaper to achieve. We would rather sequence it that way than sell a model where a solver would do.

Through integration with customs and carrier systems where interfaces exist, plus document generation, validation and archiving so paperwork is produced consistently and retained for the required period. Automated extraction from scanned documents removes a lot of manual keying, but validation matters more than extraction: an incorrectly classified shipment causes delays and penalties, so we build checks that flag uncertainty for human review rather than passing a confident guess downstream. Requirements also differ by corridor and change, so we keep the rules configurable rather than embedded in code.

The platform has to keep operating, which is why we design for this explicitly rather than treating it as an exception. Requests are queued and retried with sensible backoff, the last known status is retained and clearly marked as such rather than silently shown as current, operations staff are alerted that a specific carrier feed is stale, and manual override is available so a shipment can still be progressed. Carrier interfaces do fail, and a platform that becomes unusable when one does simply moves the problem to your phones.

Yes. Every build includes thirty days of post launch support, and beyond that we continue with monitoring, security patching, updates and new features, and can provide a dedicated senior team that extends your capacity without hiring lag. Monitoring in logistics needs to watch data freshness rather than only uptime, because the damaging failure is usually a feed that has quietly stopped updating while every dashboard still loads correctly. We alert on staleness specifically, since that is the version nobody notices until a customer does.