Ocean Freight Search → Quote → Hold → Booking

This proof of concept was about an ocean freight journey that had to move from search to quote to temporary hold to booking across multiple carriers. The product ambition sounded clean. The underlying state model was not.

The real question was whether this could be treated like a simple transactional flow or whether the platform had to own a much more explicit lifecycle. Once hold expiry, booking confirmation delay, and carrier variation enter the picture, the answer is usually the second one.

So the POC focused less on UI polish and more on orchestration shape. We built the flow around an explicit state machine: search results, quote selection, hold creation, hold expiry, booking request, and confirmation. Node.js and PostgreSQL were enough to prove the point. The important part was not the stack. It was making time and intermediate states visible instead of hiding them inside a wishful synchronous flow.

That gave us a much clearer answer about where platform ownership would need to sit. A thin pass-through approach would not have held up. If the product wanted to feel coherent across carriers, it had to normalize a messy backend reality into a platform-owned state model.

The trade-off showed up immediately. Once hold windows are real, the user journey gets more complex too. Messaging, timers, expiry behavior, and support handling all become part of the design. But that is still better than discovering late in the build that the workflow was never truly atomic in the first place.

For me, this was exactly what a POC should do. It exposed the shape of the problem early and made the eventual production cost easier to estimate honestly.