Freight software

// The problem

A regional carrier dispatches by phone and a shared spreadsheet, so customers call for status and proof of delivery reaches billing long after the drop.

// What we would build

A web dispatch board that plans and assigns loads, with an iOS and Android driver app for stops, status updates, signatures and photos, and a tracking link the customer opens instead of calling.

// What is in it

// Stack

• Next.js
• React Native
• PostgreSQL with PostGIS
• ELD and telematics APIs
• AWS

// The problem

Load tenders and rate requests arrive as emails, spreadsheets and PDFs in every layout, and a coordinator retypes each one into the TMS before anyone can quote.

// What we would build

An agent that reads each tender, pulls out origin, destination, dates, weights and references, checks them against the customer's lanes and prepares the load in the TMS for a coordinator to approve. It runs on a frontier model through its API, the fastest way to start, because tenders are routine commercial data the provider handles under its business terms.

// What is in it

// Stack

• Frontier model API
• Python
• Next.js
• PostgreSQL
• TMS API
• DigitalOcean

// The problem

Shipper, carrier and consignee each keep their own copy of the bill of lading and the delivery record, so a claim for a short or damaged load becomes an argument over whose copy is right.

// What we would build

An electronic bill of lading recorded on a private permissioned ledger where the shipper, the carrier and the consignee each run a node, so pickup, hand-offs and the signed delivery are one record none of them can change alone. If one company already runs the system and everyone trusts it, a shared database does the same job for less, and we will say so.

// What is in it

// Stack

• Next.js
• Hyperledger Fabric (private, permissioned)
• PostgreSQL
• S3-compatible storage
• AWS

// The problem

A broker offers loads to owner-operators by text message, the first reply wins, and nobody can see later who was offered which load and when.

// What we would build

A Telegram bot that posts loads to approved owner-operators, takes the first confirmed acceptance, sends the rate confirmation and asks for delivery photos at the drop, with a small admin screen for the broker.

// What is in it

// Stack

• Telegram Bot API
• Node.js
• PostgreSQL
• DigitalOcean

// The problem

Shippers and marketplaces ask for status by email and phone, and each large customer wants a feed in its own format.

// What we would build

A partner API that gives each shipper keys, a sandbox and the same shipment, status and proof-of-delivery data your team sees, with webhooks when a load moves. A developer portal and two SDKs let a shipper's developers connect without a call.

// What is in it

// Stack

• OpenAPI 3.1
• TypeScript on Node.js
• PostgreSQL
• Redis
• TMS and ELD APIs
• DigitalOcean

// The problem

A carrier quotes lanes from memory and a few spreadsheets, without knowing which lanes and customers actually cover their costs once empty miles, fuel and wait time are counted.

// What we would build

An analytics store that joins loads, fuel, driver pay and telematics every night, showing cost per mile by lane and customer including empty miles and detention, on-time delivery by shipper, and the lanes that consistently run thin.

// What is in it

// Stack

• Next.js
• PostgreSQL
• dbt
• Metabase
• DigitalOcean