Custom Software for Logistics — TMS, Freight, and Visibility That Actually Ships

A shipment is not a row in a table — it is a stream of events. Tender accepted, picked up, in transit, exception raised, delivered, invoiced. Every one of those events has to land in the right order, stay consistent across carrier feeds and EDI partners, and be visible to dispatch, the customer, and accounting at the same time. When that coordination lives in a spreadsheet and an inbox, it breaks the moment volume climbs.

We build logistics software around the event stream, not against it. Load state machines that cannot land in an impossible status. EDI translation that survives a trading partner's malformed 204. Carrier and visibility integrations with retry logic so a single upstream outage does not freeze your board. And an audit trail of every status change, rate confirmation, and document so a dispute six weeks later has a paper record instead of a guess.

Most software domains tolerate a little latency and a little inconsistency. Freight does not. A load that shows delivered in one system and in-transit in another creates a billing dispute, an unhappy shipper, and a carrier who will not haul for you next week. The data model has to enforce a single source of truth for shipment state, and the integrations feeding it have to reconcile cleanly even when one partner is hours behind.

The integration surface is the other half of the problem. A single load can touch an EDI trading partner over AS2, a parcel carrier API for the final mile, a visibility platform like project44 or FourKites, an ELD provider for position data, a factoring company for the invoice, and your accounting system for the books. Each one has its own format, its own failure modes, and its own idea of what a timestamp means. We have wired these stacks before and know where the time gets eaten — usually in the EDI mapping and the reconciliation logic, not the dashboard.

Freight fraud and double-brokering. Load boards and tender-acceptance flows are actively probed by fraud rings. We harden carrier onboarding, verify identity at the points that matter, and instrument the tender-acceptance path so suspicious patterns surface before a load gets handed to a bad actor.

Account takeover and access control. A compromised dispatcher or broker account can reroute freight and redirect payments. We wire role-based access through every surface, require MFA on privileged accounts, and log who-changed-what on loads, rates, and payment details.

SOC 2 for enterprise shippers. Large shippers and 3PLs increasingly require a SOC 2 report before they integrate. We build with Common Criteria in mind — encryption at rest and in transit, RBAC, change management, immutable audit logging — and coordinate with your auditor on evidence.

Customs and trade-program data. If your operation touches CTPAT, ACE filings, or customs brokerage data, the recordkeeping and access requirements get stricter. We do not give legal advice, but we build the audit trail and access controls your trade-compliance team will need.

EDI and partner data integrity. A garbled or replayed EDI document can create phantom shipments or duplicate invoices. We validate, deduplicate, and acknowledge every transaction, and keep an immutable copy of the raw payload for dispute resolution.

Next.js 16 on the App Router with React and TypeScript end-to-end for dispatch boards and portals. Postgres for the system of record — the relational model fits shipment state, and we lean on it for the consistency guarantees freight demands. Prisma or Drizzle as the type-safe ORM. A background worker layer (Inngest or BullMQ on Redis) for EDI processing, carrier polling, and route solves that should not block a request.

For mapping and optimization we use Google, Mapbox, or HERE depending on coverage and pricing, paired with a constraint solver tuned to your binding constraints. EDI runs through a translation layer with raw-payload archival. Carrier and visibility integrations get a normalized event model so the rest of the system never cares which provider sent a status. Sentry plus a log aggregator for observability, with PII-aware redaction. The web tier deploys to Vercel; the data plane and long-running workers go to a hardened VPC when scale or compliance requires it.

First, treating shipment status as a single editable field instead of an event log. The first time dispatch and the customer portal disagree about whether a load delivered, the company learns it cannot reconstruct the truth. Model the events, derive the status, and keep the history immutable.

Second, underestimating EDI. Trading-partner specs are full of optional segments, partner-specific qualifiers, and undocumented expectations. Teams budget a week for an integration that takes a month because the partner's test environment behaves differently from production. Build the translation layer to be defensive and log everything.

Third, optimizing the wrong thing. A research-grade route optimizer is impressive in a demo and useless if it cannot respect a real driver's hours-of-service or a customer's delivery window. We start from the constraints that actually bind your operation and move the cost-per-stop number, rather than chasing a theoretical optimum nobody can dispatch.

Logistics software is operational software — when it breaks, freight stops and money stops. You do not want the person who understands your load state machine to be a contractor three time zones away who rotates off the project next quarter. We are US-based and founder-led, and the person who designs your data model is reachable when a trading partner changes their spec at the worst possible moment.

William Beltz writes or reviews every line that touches your loads, your rates, and your settlement. NDAs are mutual and signed before discovery. Source code lives in your GitHub organization, not ours. The handoff is documented for either ongoing collaboration or in-house ownership — your call.

Logistics platforms are targeted by ransomware affiliates, freight-fraud rings, and account-takeover crews who know exactly how a tender flow works. We run penetration tests mapped to the MITRE ATT&CK techniques those adversaries actually use, then deliver a heatmap of which techniques succeed, which get detected, and which get blocked.

For the dispatch boards, carrier portals, and tracking APIs that carry the operation, web application penetration testing covers authentication, authorization, tender acceptance, and the integration endpoints fraud rings probe first. Every finding maps to ATT&CK technique IDs so your team knows what to alert on.