Turned a quickly built prototype into a platform a shipping line runs its bookings and bills of lading on.

Starting point

The first customer is a small ocean freight carrier that had been working with Excel and an industry software package. With off-the-shelf software, even small changes, like a clause in the bill of lading, often take weeks.

PASSAG3 is being built together with a good friend who has known shipping for years. He had written down the domain logic as a detailed spec and built a first version with agents: business partners, tariffs, quotes with approval, bookings, transport plans. I joined in July to turn it into something an operation can rely on.

What I build here

Deployment without ceremony

At the start I didn’t want a pipeline you wait on: “We build locally and push it straight to the server with Kamal. Otherwise we’re always waiting on CI.” A small server and one command were enough for the pilot phase in early August. When several people and agents were committing in parallel in September, automatic production deployments came in. Since then, only the exact revision that was tested goes live, and old releases are cleaned up after a successful check.

Access and roles

Before real users came in, I added mandatory two-factor login, a role model for staff, invitations with renewal and a clean path for forgotten passwords. Customer modules can be enabled per customer, so half-finished areas stay invisible during the pilot.

Data integrity for prices and bookings

Every ticket starts with a test that shows the problem. The focus was on prices, approvals and events that must be processed exactly once. Because approvers rarely log in, they now get exceptions by email.

Documents and emails

Bills of lading and quotes are PDFs that get sent out. I moved the documents from the database into object storage, built real PDF generation into the container, gave all emails a consistent design and attached generated documents. During the pilot, all mail went to a test address first until the flow was right.

Logs an agent can read

All logs land centrally in Axiom, with a dashboard for me and a skill that lets agents query the same data. That makes things like daily pilot monitoring possible: an agent reports when a burst of browser errors shows up on a booking page, and files a ticket for anything it can’t resolve. Added to that: per-request timing and alerts that remember whether they’ve already fired.

Backups that actually come back

The customer wanted to know how often we back up and how fast it’s running again. A backup that has never been restored is not an answer. So since the end of August, automated restore drills run: files from the backup are checked against checksums, and the database is restored daily into an isolated environment and checked for tables and constraints. A recovery skill describes every step, so an agent can run it too.

Daily verification

Since September, an agent with a verification skill goes through the app every evening. It knows 16 feature maps, clicks through real flows in the staff area and the customer portal, and compares them with the changes from the last 24 hours. If something is new, it updates the maps in a pull request. If it can’t prove something cleanly, it reports “blocked” instead of “green”.

Integrations and speed

On top of that came the connection to a major shipping line’s schedules via the DCSA standard for schedules, importing existing data and tariff tables from Excel, and a lot of performance work. Lists now load only what they need, the frontend no longer polls while idle, and the test suite got about 30 percent faster on two separate days.

How I work

I write little code by hand here. Agents work in separate environments, every task has clear boundaries, and writes to production are approved one by one. Tickets live in a shared project tool, sorted by priority. My part is the decisions, the review and the question of whether something actually works.

Results

The pilot has been running with real users since August, handling quotes, bookings and bills of lading in the system. Since July I’ve merged more than 120 pull requests into the platform, almost all of it foundation you can’t see from the outside. Ongoing operations now mostly means: agents read logs, check flows and speak up when something looks off. I rarely have to step in.