Port software

// The problem

A terminal plans berths on a whiteboard from agents' emails, so arrival changes reach the planner late and crane and labour bookings are redone by phone.

// What we would build

A web system where agents submit and update vessel calls, the planner drags calls onto a berth timeline that shows estimated arrivals from an AIS data provider, and cranes, labour and services are booked against each call. Hosted and run for you on AWS, with monitoring and backups. Vessel positions are for planning only, never for navigation.

// What is in it

// Stack

• Next.js
• PostgreSQL
• AIS data provider API
• Terminal system API
• AWS Canada

// The problem

A container terminal takes truck bookings by phone, so the gate is jammed at peak hours, drivers wait in line, and the clerks retype container numbers.

// What we would build

A booking site and an iOS and Android app where trucking companies book time slots against containers that are ready, a QR code the gate scans on arrival, and plate and container readers at the gate that match the truck to its booking. Slot rules and limits are set by your operations team.

// What is in it

// Stack

• Next.js
• React Native
• PostgreSQL
• Terminal system API
• Gate reader integration
• AWS Canada

// The problem

A group of marinas takes slip and moorage bookings by phone and email, keeps boaters' documents in a filing cabinet, and answers the same questions about fuel, pump-outs and rates all season.

// What we would build

A booking site designed around your brand where boaters reserve transient slips and seasonal moorage and pay online, upload insurance and registration documents, and find answers in a help centre with an assistant in several languages. Bookings and payments are posted to QuickBooks Online, built on its API.

// What is in it

// Stack

• Next.js
• PostgreSQL
• Stripe
• Frontier model API
• QuickBooks Online API
• DigitalOcean

// The problem

A port authority pulls vessel movements, berth use and cargo figures from several systems and AIS feeds into spreadsheets for every monthly report.

// What we would build

A data warehouse that takes AIS feeds, the terminal system and berth records on a schedule, checks them for gaps and duplicates, and shows calls, dwell times, berth use and cargo on dashboards, with the monthly report filled in automatically. For planning and reporting, never for navigation.

// What is in it

// Stack

• PostgreSQL
• dbt
• Metabase or a custom dashboard
• AIS data provider APIs
• DigitalOcean

// The problem

A terminal runs a terminal operating system, a gate system, billing and a port community system that do not talk to each other, so staff copy vessel and container data between them all day.

// What we would build

An integration hub that keeps the terminal operating system, the gate system, billing and the port community system in step through one internal API, with webhooks for changes, retries when a system is down, and a log of every message. Built on each system's published API; we check yours before we quote.

// What is in it

// Stack

• Node.js
• PostgreSQL
• OpenAPI
• Message queue
• DigitalOcean

// The problem

Shipping agents, terminals and ship repair yards each ask for the same crew and vessel certificates, PDFs are passed along by email, and no one can tell whether a copy has been changed or has expired.

// What we would build

A register where the issuing party or the vessel's agent uploads each certificate once, its fingerprint recorded on a private permissioned ledger that agents, terminals and yards each run a node of, with expiry reminders and a lookup for everyone the agent grants access. A shared portal with signed PDFs often does this job; the ledger helps when several organisations rely on the same record and none wants to hold it for the others.

// What is in it

// Stack

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

// The problem

A ship repair yard paid a vendor to replace its Access database for work orders and equipment maintenance; the rebuild stalled half done, and the yard still runs on the old database.

// What we would build

An architecture review first, with a written finding on what in the stalled build is worth keeping, then a rescue: the work-order system finished on the parts that hold up, an Android tablet app for the yard floor, equipment maintenance schedules, and every record moved from Access and checked. Hours and parts post to QuickBooks Online. Maintenance intervals are the ones your engineers set.

// What is in it

// Stack

• Next.js
• Kotlin for Android
• PostgreSQL
• QuickBooks Online API
• DigitalOcean