[HN Gopher] Launch HN: Greywing (YC W21) - Automated ship operat...
___________________________________________________________________
Launch HN: Greywing (YC W21) - Automated ship operations focused on
crew
Hey HN! We're Nick & Hrishi, founders of Greywing (https://grey-
wing.com). Greywing is software that optimizes operating a vessel
in the high seas, focused on seafarers and crew changes. We take
the information you (a ship manager) have about a vessel (route,
plans, crew composition), plus information externally available
(piracy, flights, fuel costs), and tell you where to route your
vessel and what the best choices are for the crew, and the
purchases you're making. Maritime is a surprisingly decentralized
industry, even in 2021. Large vessels (container ships, gas
tankers) are complex entities, with a single vessel operated
simultaneously by multiple companies (ship managers, charterers,
technical managers, crew managers) domiciled in different
countries. These companies manage flights, fuel purchases and
consumption, cargo and charters, crew welfare, and a hundred other
things that go into completing a single trip. Once a trip is done,
most of these things change before the next voyage. There is often
no central source of truth for any of this data, let alone systems
that connect one to the other. Parties involved--travel managers,
port agents, vessel captains--communicate over email, with no clear
idea of what the other hand is doing. This means that a single crew
change can take up to a week to decide, with no clear idea if it
was the optimal outcome. Crew changes had been getting more complex
for a while, with increasing budgets and slowdowns, but Covid
turned this into a humanitarian crisis [1], with over 800,000
seafarers stuck at sea or unable to work for more than a year.
Vessels are often short-staffed and overworked due to lack of
space, so crew operate on three to six month contracts and spend
about the same amount of time on land. As crew rotate, you have an
exchange of oncoming crew (onsigners) with outgoing crew
(offsigners). Crew managers try to do this with minimal disruption
to the route, while making sure the crew don't overstay contracts
and the vessel consumes fewer resources (fuel, flights, etc). Crew
managers work with imperfect information under time pressure, and
the wrong decision (or no decision) can cost thousands of dollars
and have strong impacts. Tired crew that haven't been home in a
long time make mistakes (and these mistakes have increased in
recent past), but deviating too far from cargo requirements will
take a vessel off-hire. A bit about us: Nick is a maritime native,
having worked on vessels and done many of the jobs we serve today,
all the way up to running a maritime startup for 10 years. I
(Hrishi) spent most of my career in a diverse set of industries,
from fast-moving ones like crypto and robotics to the other end of
that spectrum with reinsurance and semiconductor ball bonders. We
met in Singapore after Nick uprooted his life to start something
new. Having seen the effects of 2008 on the maritime industry, we
felt that we could build software that increased the resiliency of
shipping to systemic shocks. We started in 2019, and as it turns
out a pretty big shock was around the corner. Since then, our goal
has been to solve problems with human-augmentation, by automating
as much as possible and then getting out of the way of the people
who operate a vessel. Having started in maritime security, one of
our first successes was in building a real-time dataset for piracy
around the world. Incidents are usually reported to local
authorities, and published in pdf bulletins on separate sites. The
next step was turning this into structured data, and connecting it
to an internal database of ports, as well as a routing tool that we
had to build from scratch. By the time we focused on crew and the
effects of Covid, we had most of the tools we needed to tackle the
issue, and it became a job of incrementally adding connections to
our data around airports, flight prices, agency costs, fuel
consumption, so on. We combine this information to provide
immediate guidance on where a vessel should go, and what actions it
should take along the way. We use the data at our disposal, both
public and private, to optimize for the best route for the vessel
so it can change crew, while burning the least fuel, spending less
on flights, and where immigration and port restrictions are open
[2]. It's basically n-dimensional pathfinding, once you've got
clean relational data. We do this through our intelligence tool
CRY4 (named after [3]), and to date we estimate that we've saved
our customers over 20,000 USD per vessel per year. So far, we've
automated over 50,000 crew changes and are now monitoring more than
a thousand vessels, while saving our customers more than 20,000 USD
per vessel per year. We've had users turn to Greywing to evacuate
critically wounded crew as fast as possible, organize nation-wide
exercises to conduct charter flights to alleviate some of the
still-building pressure around ports, among other things we've
written about [4]. We're humbled by the effect software has had on
this problem, and some days it's still surreal to think of code
that didn't exist 6 months ago making a difference in maintaining
global trade networks. We'd love your feedback on what we've
built. We've just expanded to a team of three, and are hiring
frontend developers. Our priorities are UX and algorithms - solve
problems with good software, and build interfaces that make those
solutions useful. We'd love to hear any feedback you have, and are
happy to answer any questions! [1] https://hrishioa.github.io/one-
million-mariners/ [2] https://blog.grey-wing.com/why-deep-tech-is-
the-future-of-ma... [3] https://www.pnas.org/content/116/39/19449
[4] https://blog.grey-wing.com/a-vessel-manager-us-2-5-million-7...
Author : hrishi
Score : 83 points
Date : 2021-03-29 13:32 UTC (9 hours ago)
| atlasunshrugged wrote:
| I have a bit of an out there question but maybe you know the
| answer as I see you've done some piracy mapping. Is there any
| tech that's addressing the piracy issue that you think is just
| phenomenal (also thinking about unlicensed fishing in poorer
| countries territorial waters they can't defend but maybe the
| overlap isn't that great)? My understanding is basically this has
| been resolved by 1) ships routing through well controlled seas or
| 2) ships hiring additional private security for staffing on ship
| or as escorts. Is that correct?
|
| Edited because I have no manners - congratulations on the launch
| too, I didn't see your pitch but the product sounds really cool
| and I'm sure shipping is top of mind for everyone right now!
| hrishi wrote:
| Thanks! Nick can chime in here once he's up - I'm the night owl
| (we're on SGT) and he's up in a few hours.
|
| But the way I see it, most of the problems around piracy are
| systemic. I'll skip going into too much detail, but when
| economies are set up to benefit from a rise in pirate activity
| in their borders, you've created a loop that removes incentives
| to find a long-term solution.
|
| The solutions have been exactly what you've suggested. One
| option for highly trafficked routes (like the Gulf of Aden) is
| to control a narrow part of the route well, so ships can use
| it. The IRTC[1] is a good example.
|
| The other option is security. However, security may not always
| be possible. One reason is price (when we started Greywing, the
| per day cost of a security vessel sometimes exceed that of the
| tanker it was guarding!). The other is that security is still a
| volatile market, especially since suppliers always have to be
| located in the countries you're closest to. Security companies
| can pop in and out of existence, and the service is often a far
| cry from what you pay for.
|
| There has been some work in the technology on the vessels -
| better training for the crew, better citadels, nonlethal
| deterrents, etc. However, these can only go so far when you're
| comparing the resolve of a pirate vessel to that of the crew on
| a tanker to survive.
|
| From a software standpoint, routing makes a difference, but not
| as much as you might think. If a vessel needs to call at a
| port, there are often unavoidable routes that need to be taken.
| However, some of the early work we were doing focused on making
| sure that the captains and crew had a good idea of high and low
| alert days, as well as an idea of the mitigation measures to
| undertake to prepare for them.
|
| Some of the products that were serving the security market when
| we started have since gone out of service, and I'm not
| personally aware of any yet that focus on operators, rather
| than nation-states and intelligence agencies. There's still
| open demand for services that focus on establishing trust and
| reputation around suppliers, aggregating good services, and
| enforcing due diligence.
|
| This took me down a rabbit hole of our videos, but [2] is an
| example of what CRY4 looked like in the early days, when it was
| just piracy!
|
| [1] -
| https://en.wikipedia.org/wiki/International_Recommended_Tran...
| [2] - https://vimeo.com/393361342
| atlasunshrugged wrote:
| Ah, that's super interesting. The systemic issues make sense
| but I do wonder about incursions from foreign powers (e.g.
| Chinese fishing trawlers in W. Africa) but maybe these belong
| to a different category of issue.
|
| RE Security & Pricing - that's fascinating. I would have
| expected this to be a standard business affiliated with the
| big insurers and run out of the big private contracting
| companies (e.g. Academi). Most of the tech I've seen is also
| for close proximity to the boat (e.g. water cannons, slippery
| mesh, stun grenades), is it because the ships can't engage
| until the pirates are very obviously going to attack? In my
| head I'm imagining patrols of swarm drones that drop boat
| trap nets before the boats can get very close to the ship
|
| But all this is really cool, thanks for the response!
| fplaza wrote:
| Congrats on the launch! Saw your demo day pitch and super
| impressed
| TriNetra wrote:
| Congratulation! Looks like a quite an interesting problem and
| domain to build software for.
|
| How did you get your first customer? Was it easy because of Nick
| connections or, did the customer require lot of convincing and
| value demonstration?
| hrishi wrote:
| Thanks! It's a mixture of all of these things, to be honest. We
| had visibility into and in the industry due to our work with
| maritime security, as well as the benefit of being in an
| uncontested space (vessel operations intelligence) which was in
| crisis.
|
| However, our first customers were inbound, from the demos we
| uploaded explaining how CRY4 could help with security and
| operations. So it's likely all of these things combined - we've
| worked to understand what drove initial adoption, but as we
| become more established we're seeing that these drivers shift
| into different things. What's driving leads today, I think may
| not be these things exactly.
| InGoldAndGreen wrote:
| Congrats on the launch! Looks like an awesome product
|
| What do you find your customers care about the most?
| Security, cost savings, UI? It seems like a pretty old-tech
| industry that you're digitalizing, so I'm curious about what
| the pull is from their side
| hrishi wrote:
| It's a mix really: all of them care about the cost savings,
| but the UI and the opportunity to digitize and connect
| different parts of the business have also been strong
| drivers.
|
| First-generation software has been around just long enough
| in maritime that a lot of organisations are feeling the
| pain from having multiple solutions that don't connect and
| are starting to show their age.
| carabiner wrote:
| Cool ideas! Side note to @dang, it's hard to read text blocks
| like this in HN's light grey font. I copied and pasted it into a
| notepad window to increase the contrast.
| beansontoast wrote:
| Could you tell me in a sentence what the product does?
| hrishi wrote:
| We take all the information you (a ship manager) have about a
| vessel (route, plans, crew composition), with all the
| information externally available (piracy, flights, fuel costs),
| and tell you where to route your vessel and what the best
| choices are for the crew, and the purchases you're making.
|
| Does that help? Happy to try again, it's a pretty complex piece
| of software that simplifies a complex job: unfortunately we're
| not as good as our software at simplifying the explanation.
| jhgb wrote:
| > unfortunately we're not as good as our software at
| simplifying the explanation
|
| You mean the software provides explanations for its outputs
| and decisions, in the classic AI style? Or did that mean
| something else?
| hrishi wrote:
| I meant we're not as good at simplifying the narrative, as
| we hope Greywing is at simplifying the task of vessel
| operations :)
|
| We don't currently use any AI - we're yet to exhaust
| deterministic knowledge-based algorithms, but it might be
| something we look at in the future.
| jhgb wrote:
| Classic AI can definitely be deterministic and knowledge-
| based. It just sounded from that phrasing like you went
| down the "explainable outputs" route that is sometimes a
| part of such approaches (see expert systems, for example)
| and that is commonly missing these days (which may lead
| to people using outputs of complicated decision-making
| systems asking questions like "why would we want to do
| _that_? ").
| dang wrote:
| That sentence is good! I've added it to your blurb above :)
| heuroci wrote:
| This looks good! Complex industry with archaic tools so it is
| great to hear you had done some business already! Can you
| elaborate how much of the business you generated was more like
| consulting vs the customer using the packaged solution?
| hrishi wrote:
| Thanks! Our process has been client-driven from day one: we've
| got a good amount of technical and maritime expertise on our
| side, but it pales in comparison to the mountain of operational
| knowledge that our users have.
|
| What this means is that all of our clients came on for the
| solution we were offering at the time, but each has had a
| strong impact on what the tools became, and what modules we've
| offered since then.
|
| As an example, our first customer came on board for Covid-19
| risk reporting (to improve communications with port
| authorities), fleet tracking and our routing tool. Under their
| direction, we released our port scanning tools and geofencing-
| related modules. Our second customer bought this product, and
| with their help we've been able to release (to name a few) a
| communications tool for port agents and flight tracking and
| heuristics.
|
| This has been a good model for us: the benefit to us is an
| increasing price point for new customers as well as the ability
| to learn from parts of this process that wouldn't have known
| about otherwise, and the existing customers aren't charged for
| new modules and improvements.
| heuroci wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| corry wrote:
| Congrats on the launch! Wondering how much overlap you have with
| Flexport, which I've followed with great admiration through the
| years. Definitely seems like a sector in major need of continued
| modernization.
| hrishi wrote:
| Thanks! Interesting that you ask that - we have very little (if
| any) overlap with Flexport. They focus on the cargo and the
| freight, and we focus on operations. We've definitely helped
| operate some of their vessels in the past!
|
| There is a future where the two parts come together, as their
| fates are always linked, but it's outside the scope of
| complexity for us today, and for Flexport as well I imagine.
| corry wrote:
| Makes sense! Chalk it up to ignorance on the sector in
| general, when I think "ships and startups" I think Flexport.
| I bet a lot of VCs will too (which is great - they are
| absolutely stellar). Best of luck!
| deanebarker wrote:
| I remember that the main, central example in "Domain Driven
| Design" was basically software like this.
| hrishi wrote:
| I agree. I forget who I'm quoting (and butchering), but it's
| become one of my favorite aphorisms that "Data is everything.
| Once you have the right data structures and relationships, the
| algorithms are apparent."
| hiq wrote:
| Linus Torvalds said something similar.
| the-dude wrote:
| Isn't that quote much older and from EWD or Aristotle?
| hrishi wrote:
| Could be! Sometimes things get stuck up there and over time
| weather down to something I can no longer Google or
| remember attribution for :)
| heuroci wrote:
| The domain is also ripe with algorithmically interesting
| problems.
|
| One issue I have seen though is the mindset of the business
| user may not be very tolerant of probabilistic results.
| hrishi wrote:
| Completely agreed - and it's something we've had to work very
| hard at.
|
| A rule of thumb that's worked for us is that the more
| information you show, the more tolerant your users are.
| However, that's also directly in opposition to the fact that
| the more information you show, the less user-friendly your
| product becomes.
|
| Our approach has been to pyramid up the information we have.
| When we integrate a new source of data, we initially run
| customer engagement and have internal sanity checking
| algorithms to make sure we have a decent confidence about the
| data that we present. At this stage however, we give the user
| more information than less - so a full cost breakdown of a
| port call, instead of indicative total estimate, for example.
|
| User engagement and testing will then help us understand
| which pieces are being used the most, and how we can best
| condense the data down in a way that best helps the user.
| This also gives us more time to refine our backend so that we
| have a higher degree of confidence about our methodology and
| results.
|
| This often results in big changes - a twenty paragraph
| statement of restrictions may be condensed into a traffic
| light on whether a certain nationality is accepted into a
| port, or a fuel table may be condensed into a single estimate
| of cost based on estimated weight of the ship. This approach
| has worked well for us, and it might help in similar fields.
| heuroci wrote:
| Are you familiar with quad keys and quad tiles? If not
| definitely read up. Could simplify a lot of routing and
| tracking: https://wiki.openstreetmap.org/wiki/QuadTiles
| hrishi wrote:
| We've been using PostGIS' internal storage mechanism for
| routes and tiles so far. We've attempted to build our own
| indexing (through quadtrees indexed similar to OSM's),
| but it's never crossed the performance we get by default
| from PostGIS.
|
| It's not a bottleneck yet, but I'm sure we'll be
| revisiting this soon. Thanks for the link! I hadn't found
| this one yet - super helpful.
| ahstilde wrote:
| Did the Suez crisis have any implications for your business?
| hrishi wrote:
| None directly, but we believe improving crew well-being and
| providing more assistance to ensure vessels operate smoothly
| will have a long-term impact.
|
| Ships can only function as well as the people on-board, but
| it's an often overlooked part of the industry.
| ghiculescu wrote:
| Just gotta say, building a real time piracy database is one the
| coolest projects I've ever seen on here. It's easy to forget that
| pirates still exist.
|
| Best of luck to you both!
| hrishi wrote:
| I didn't know that either until I joined maritime! They are
| still very much a thing, and Nick could tell you stories
| forever - in some cases it's a well oiled machine, where the
| pirates know the insurance negotiators and vice versa.
|
| It's also an unfortunate result of conditions today. If you
| look at some of our risk maps [1] you'll see that the hotspots
| are pretty consistent and predictable. Somalia, Nigeria,
| Malacca Strait, etc.
|
| 1 - https://grey-wing.com/intelligence-reporting
___________________________________________________________________
(page generated 2021-03-29 23:01 UTC)