[heuroci]

This is indeed a great model that works well when the problems one client has can scale to others without a ton of customization.

What has been the most challenging aspects technically and business wise for you so far? What has been the most exciting/rewarding?

[hrishi]

The most challenging aspect for us has been getting integrations with client software done and out of the way. Unlike other industries, the existing software around crew, reporting and planning are often in-house and in some disrepair, from a first-wave of digitization. This has pleasantly not been the case sometimes, but often we need to build the pipes ourselves - sometimes on both sides!

Our integrations range from SOAP, REST, FDW as well as push, pull, batch, and almost all combinations of these. Getting them done can also mean cleaning and consolidating the data we receive, so the users have a seamless experience.

Integrations can make a big difference in the UX as it stands, and our work the past few weeks have been focused on building graceful circuit breakers for our modules so that the the experience works as well as it can even without automated data.

Another one is definitely customization, but it's been rewarding for us. We've definitely had to customize the product to better suit the workflows of our customers. Maritime is a pretty heterogeneous place when it comes to details, but I think we're now at a point where most of the requests we get are already built into the product - customization is becoming just a matter of config.

The most rewarding aspect technically has been to watch new solutions emerge as a result of having a clean graph of data with well built relationships. There are a number of zero-to-one problems in maritime tech (routing, ports, events, etc) that I believe prevent new entrants into the space - much like ride-sharing would not be as easy without a good map element, GPS and cellular data.

Once those are solved, it's been rewarding to take unrelated requests from clients (around withholding or corporate tax, for example) and realize that you've got 99% of the tech needed to deliver a good solution.

From a business perspective, it's been a harder journey than we expected to get parts of the industry to open up about data or collaboration. It's significantly easier once you've built momentum, so it's also been rewarding to collaborate across stakeholders - from port agents and crewing unions to marine travel companies - as of late.

[heuroci]

I don’t know know your stack so take this with a grain of salt:

It may be very tempting at times to skip normalizing data and to just throw stuff in a document store. The downside will be code complexity and runtime that is less than performant.

I am sure you are familiar but the patterns “adapter” “strategy” and “interpreter” can be very valuable here

I am sure you also use dependency injection as appropriate . I wish you all the best. I will keep an eye on and think good thoughts

[hrishi]

We've been using a mutated blend of our own patterns with the ones you mentioned, but you're 100% spot on.

The reason we have a product today with 100% uptime and reasonable tech debt is that we front-loaded the cost of data by making sure we normalize (which is non-trivial in maritime), along with cleaning and consolidation with other sources. We also have our own internal consensus algos that pull multiple sources where possible and pick the most likely.

And hopefully this is an anecdotal data point for anyone, but we've been running a pretty performant system that services 200,000 ports, 50,000 airports, 50,000 crew, 5000 vessels and millions of miles of GeoJSON routes in real-time with Postgres alone. In my experience a well organised relational db can outrun most document stores, in most applications.

The only caveat I'd say (if there is one) is normalization as a hard rule. We denormalize some fields when we need to squeeze performance out of a commonly accessed metric (caching essentially, but through the db which I think makes it denormalization), and it's been quite helpful. Of course you need stronger checks and balances in code to make sure things don't desync, but it can be helpful to speed up large, common queries.

I'll link some of the technical write-ups of how we use Postgres and PostGIS below in [1] and [2], if anyone's interested.

[1] - https://hrishioa.github.io/large-geospatial-queries-and-opti... [2] - https://hrishioa.github.io/subqueries-and-ctes-an-example-of...