Dimitris Lyras

The shipowner who built software for the oldest industry on earth

By VastBlue Editorial · 2026-03-26 · 16 min read

Series: The Inventors · Episode 8

90 Percent of Everything

Approximately ninety percent of global trade, by volume, moves by sea. The shirt you are wearing was probably on a container vessel at some point. The steel in the building you are sitting in almost certainly was. The fuel in the car you drove this morning was refined from crude oil that crossed an ocean in a tanker. Maritime shipping is the circulatory system of the global economy — so pervasive, so fundamental, so ordinary that most people never think about it. You do not notice your blood until you are bleeding.

The numbers are staggering in their scale. More than eleven billion tonnes of cargo move by sea every year. The global merchant fleet comprises over 100,000 vessels — container ships, bulk carriers, tankers, gas carriers, general cargo ships — collectively valued at hundreds of billions of dollars. The largest container vessels, the Ultra Large Container Ships that ply the Asia-Europe trade route, carry over 24,000 twenty-foot equivalent units (TEUs) — enough containers, if laid end to end, to stretch nearly 150 kilometres. A single voyage of a large bulk carrier can transport enough iron ore to manufacture the steel for a small city's worth of buildings. The scale is industrial in the most literal sense. It is also invisible. The consumer who orders a product online sees a delivery van. They do not see the 400-metre vessel that carried the container across 8,000 nautical miles of open ocean to get it there.

This entire system depends on a network of physical chokepoints — narrow passages where geography compresses global trade into corridors a few hundred metres wide. The Suez Canal handles roughly twelve percent of global trade. The Panama Canal handles about five percent. The Strait of Malacca, connecting the Indian Ocean to the Pacific, carries a quarter of all seaborne oil. The Strait of Hormuz, barely 33 kilometres wide at its narrowest, sees a third of the world's liquefied natural gas pass through it. When any of these chokepoints is disrupted, the consequences cascade through the global economy within days.

In March 2021, the Ever Given — a 400-metre container vessel carrying 18,300 containers — ran aground in the Suez Canal, blocking it for six days. The blockage held up an estimated $9.6 billion worth of trade per day. Over 400 vessels queued at both ends of the canal. Supply chains that had been optimised for just-in-time delivery discovered that "just in time" assumes the canal is open. The COVID-19 pandemic had already demonstrated the fragility of maritime logistics: port closures, container shortages, crew change crises caused by travel restrictions, and demand surges that overwhelmed port infrastructure led to shipping costs increasing by 400 to 700 percent on major routes. Freight rates from Shanghai to Rotterdam, which had hovered around $2,000 per container for years, spiked above $14,000. The world was reminded, briefly and painfully, that maritime shipping is not a commodity service operating in the background. It is a critical infrastructure system whose failure can destabilise national economies.

The maritime industry predates the Roman Empire. Phoenician merchants ran commercial shipping routes across the Mediterranean three thousand years ago. The East India Company operated a global fleet in the 1600s. Container shipping, standardised in the 1950s by Malcom McLean, transformed world trade by making cargo interchangeable — any container fits on any ship fits on any truck fits on any train. The physical logistics of moving goods by sea are, by any historical measure, extraordinarily well understood.

The information logistics are not. When Dimitris Lyras began building Ulysses Systems in the 1990s, the gap between the physical sophistication of maritime operations and the informational primitiveness of maritime management was staggering. A modern container vessel — a machine costing $150 million, carrying $500 million in cargo across 10,000 nautical miles — was being managed with paper logs, fax machines, and telephone calls between ship and shore. Maintenance schedules were tracked in ring binders. Crew certifications were filed in cabinets. Port state inspection histories existed on paper forms in harbour masters' offices. The physical asset was 21st century. The information systems were mid-20th century. Sometimes earlier.

The Information That Keeps Ships Floating

Lyras understood this world from the inside. He came from a Greek shipping family — the Lyras family has operated vessels in the Mediterranean for generations — and had trained as a mechanical engineer before entering the family business. What he saw was not a technology problem. It was an integration problem. The data existed. It was scattered across filing cabinets in Piraeus offices, logbooks in engine rooms, fax archives in port authorities, spreadsheets on superintendents' laptops, and the personal notebooks of chief engineers who carried their institutional knowledge in their heads and took it with them when they rotated off.

A modern commercial vessel generates an extraordinary volume of operational data. Engine performance metrics — temperature, pressure, vibration, fuel consumption — are recorded continuously by onboard monitoring systems. Maintenance tasks — scheduled overhauls, unscheduled repairs, class-required surveys — accumulate on timelines that span years. Crew certifications — STCW qualifications, medical fitness certificates, visa validity, flag state endorsements — expire at different intervals for different crew members under different jurisdictions. Cargo documentation — bills of lading, dangerous goods manifests, stowage plans, customs declarations — must be accurate and available at every port of call. Safety management systems — ISM Code compliance, emergency drills, incident reports — must be auditable at all times.

Consider the crew certification challenge alone. A typical commercial vessel carries between 20 and 25 crew members. Each crew member holds multiple certificates: a Certificate of Competency for their rank, STCW endorsements for specific functions (bridge watchkeeping, engine room operations, medical first aid), a flag state endorsement from the vessel's country of registration, a medical fitness certificate, possibly a seafarer's identity document, and visa documents for the countries whose ports the vessel will visit. Each of these documents has a different expiry date. A chief officer's Certificate of Competency might expire in five years. His medical certificate expires in two. His Panamanian flag state endorsement expires in three. His Schengen visa expires in six months. Multiply these overlapping expiry dates by 22 crew members, and the management office onshore is tracking over a hundred certification deadlines that, if missed, can result in a vessel being detained at its next port inspection.

The consequences of poor information management in shipping are not theoretical. A vessel detained in port for a documentation deficiency — an expired certificate, a missing survey record, a non-conformity in the safety management system — costs its owner between $15,000 and $50,000 per day in port charges, idle crew costs, and lost charter revenue. But the detention itself is only the beginning. Port state control authorities share detention records through international databases — the Paris MOU, the Tokyo MOU — and a vessel with a detention history faces higher inspection rates at every subsequent port. Insurers increase premiums. Charterers, who have their own reputational concerns, may refuse to charter vessels from companies with poor inspection records. A single information failure — a certificate that expired because nobody in the management office noticed — can trigger a cascade of financial and reputational consequences that persists for years.

On the maintenance side, the failures are even more consequential. A bulk carrier's main engine contains thousands of components with different maintenance intervals — piston rings that need inspection every 8,000 running hours, fuel injectors serviced every 4,000 hours, turbocharger overhauls at 12,000 hours, full crankshaft inspections at 24,000 hours. When these schedules were tracked on paper — in the chief engineer's personal maintenance log, supplemented by ring binders of manufacturer's service bulletins — tasks were missed. Not frequently, but predictably. A chief engineer rotates off after four months. His replacement inherits the maintenance log but not the context — the note about the number three cylinder showing slightly elevated exhaust temperatures, the verbal agreement with the superintendent to postpone the turbocharger overhaul until the next drydocking. The institutional knowledge walks off the vessel with the departing crew. The replacement starts from the written record, which is incomplete. Months later, the turbocharger fails at sea.

Ulysses Systems

Ulysses Systems — named, with the literary instinct characteristic of Greek shipping families, after the mythological mariner — developed task-based vessel management software that connected ship and shore operations. The system tracked maintenance tasks, regulatory compliance deadlines, procurement workflows, and operational performance in a single platform accessible to both the crew aboard the vessel and the management team onshore. But calling it "vessel management software" understates the engineering challenge. Enterprise resource planning systems existed in other industries. SAP ran factories. Oracle ran supply chains. The technical concepts were well established. What made maritime software fundamentally different was the environment in which it had to operate.

Ship-Shore Synchronisation: The Hardest Problem

The defining engineering challenge of maritime software is connectivity — or more precisely, the lack of it. A vessel at sea communicates with shore via satellite. In the 1990s and 2000s, when Ulysses was being developed and deployed, maritime satellite connectivity operated through systems like Inmarsat Fleet, which offered bandwidth measured in kilobits per second — not megabits, not gigabits, kilobits. A connection that a shore-based office worker would consider unusable was the best a vessel could get. And it was expensive: satellite airtime was billed per kilobyte, at rates that made every byte transmitted a cost consideration. Sending a photograph over satellite could cost several dollars. Streaming anything was out of the question. Even today, with newer VSAT systems offering higher throughput, maritime bandwidth remains constrained and expensive compared to terrestrial connectivity, and coverage gaps persist in high-latitude waters and remote ocean areas.

This constraint shaped the entire software architecture. Ulysses could not operate as a cloud application with a constant connection to a central server — the model that every modern SaaS company takes for granted. It had to run as a fully functional local system aboard the vessel, capable of operating independently for days or weeks at a time, and then synchronising with the shore-based system when connectivity was available. This is the offline-first design pattern, and implementing it for a multi-user transactional system with regulatory compliance requirements is orders of magnitude harder than building a conventional client-server application.

The synchronisation problem is where the real complexity lives. While the vessel is at sea, the chief engineer records a completed maintenance task in the shipboard system. At the same time, the superintendent onshore updates the maintenance schedule based on a revised class survey deadline. When the two systems reconnect, they must reconcile these changes. In simple cases — different records modified by different users — the merge is straightforward. But in complex cases — the same maintenance task modified independently by ship and shore, or a procurement order approved onshore that the vessel has already cancelled — the system must apply conflict resolution rules that preserve data integrity without requiring real-time human intervention. The vessel cannot wait for the office to resolve a database conflict. The office cannot wait for the vessel to confirm a merge. The algorithm must handle it automatically, correctly, and auditably.

The synchronisation protocol also had to be extraordinarily efficient in its use of bandwidth. Rather than transmitting entire databases, the system transmitted only the changes — deltas — since the last successful synchronisation. These deltas were compressed, prioritised (safety-critical updates before routine maintenance records), and transmitted in packets small enough to survive the intermittent satellite connections. If a transmission was interrupted — as frequently happened when a vessel passed through a coverage gap or the satellite antenna lost lock in heavy seas — the protocol had to resume from where it left off rather than retransmitting from the beginning. Every aspect of the system was engineered around the constraint that bandwidth was scarce, expensive, and unreliable.

Lyras did not build Ulysses by hiring Silicon Valley engineers and explaining ships to them. He built it by understanding both domains — the maritime operational reality and the software engineering required to serve it. This dual fluency is rare and valuable. Most technology companies that attempt to serve traditional industries fail because they understand the technology but not the domain. They build elegant solutions to problems that the industry does not have, while ignoring the ugly, specific, regulation-encrusted problems that the industry actually struggles with.

The Regulatory Labyrinth

Maritime shipping operates under one of the most complex regulatory frameworks of any industry on earth. The International Maritime Organisation, a United Nations specialised agency, administers a web of international conventions that govern every aspect of vessel construction, operation, crewing, and environmental impact. Understanding these regulations — and what they actually require of vessel operators in daily practice — is essential to understanding why maritime software is so much harder to build than it appears.

The International Safety Management (ISM) Code, adopted in 1993 and mandatory since 1998, requires every shipping company to establish a Safety Management System (SMS) — a documented set of procedures covering every operational activity from bridge watchkeeping to engine room maintenance to cargo handling to emergency response. The SMS must designate a Designated Person Ashore (DPA) responsible for monitoring safety and pollution prevention. Every vessel must carry a Safety Management Certificate (SMC), and every company must hold a Document of Compliance (DOC). Both are subject to annual verification audits by the vessel's flag state administration or a recognised organisation acting on its behalf. These audits examine not just whether the documentation exists, but whether the procedures are actually being followed — whether the drill records match the drill schedule, whether the maintenance records demonstrate that the planned maintenance system is being implemented, whether non-conformities identified in previous audits have been corrected. An auditor who finds a "major non-conformity" can withdraw the SMC, effectively preventing the vessel from trading.

SOLAS — the International Convention for the Safety of Life at Sea, first adopted after the Titanic disaster in 1914 and revised repeatedly since — sets mandatory standards for ship construction, fire protection, life-saving appliances, radio communications, and navigation. It requires periodic surveys by classification societies — the independent technical bodies (Lloyd's Register, Bureau Veritas, DNV, ClassNK, ABS, and others) that certify a vessel's structural and mechanical fitness. A typical commercial vessel undergoes an annual survey, an intermediate survey every two to three years, and a special survey every five years, each progressively more comprehensive. The special survey may require sections of hull plating to be gauged for thickness, ballast tanks to be inspected internally, and machinery to be opened up and examined. Each survey generates findings that must be addressed within specified timeframes, and the completion of corrective actions must be documented and verified.

MARPOL — the International Convention for the Prevention of Pollution from Ships — regulates emissions, ballast water treatment, garbage disposal, and the discharge of oil and chemicals. Its annexes cover everything from sulphur content in fuel oil (which must not exceed 0.50 percent globally since 2020, and 0.10 percent in Emission Control Areas) to the management of sewage from vessels to the handling of anti-fouling systems. Each regulation carries its own documentation requirements, its own inspection regime, and its own penalties for non-compliance. A vessel operating in the North Sea Emission Control Area with fuel exceeding the 0.10 percent sulphur limit faces fines that can reach six figures, and the master of the vessel may face criminal prosecution in some jurisdictions.

Layered on top of these international conventions are flag state requirements (the regulations of the country where the vessel is registered), port state requirements (the regulations of the country whose port the vessel is visiting), class society rules, insurance conditions (P&I Club requirements), and charterer's vetting requirements. A vessel registered in the Marshall Islands, classed with Lloyd's Register, insured through the UK P&I Club, and trading between ports in the European Union, the United States, and China is simultaneously subject to at least six different regulatory regimes, each with its own documentation requirements, inspection schedules, and compliance deadlines.

This regulatory complexity is why maritime software cannot be a generic project management tool with a nautical theme. Every maintenance task has a regulatory dimension. Every crew assignment has a certification dimension. Every voyage has a compliance dimension. The software must encode the relationships between these regulatory requirements and the operational activities they govern — automatically flagging when a planned maintenance task is approaching a class survey deadline, when a crew member's certification will expire before the vessel's next scheduled crew change, when a voyage plan will take the vessel into an Emission Control Area where its current fuel may not comply. Lyras understood that the software was not just a record-keeping system. It was, in practice, the vessel operator's regulatory compliance engine.

The IMO and Mandatory Digitisation

Lyras became an active participant in the International Maritime Organisation's efforts to digitise shipping operations. The IMO's FAL Convention (Facilitation of International Maritime Traffic) has progressively mandated electronic submission of arrival and departure information, cargo manifests, crew and passenger lists, and dangerous goods declarations. Since 2019, ships calling at ports in IMO member states are required to submit this information electronically rather than on paper. The Maritime Single Window concept — a single point of electronic data submission for all port call information — has been mandatory since January 2024, requiring ports worldwide to accept standardised electronic messages rather than paper forms.

These regulatory mandates validated the direction Lyras had been pursuing for two decades. The maritime industry was being compelled — by international regulation, by insurance requirements, by the competitive pressure of more efficient operators — to treat information as a managed asset rather than a bureaucratic byproduct. Companies that had adopted systems like Ulysses years earlier found themselves ahead of the regulatory curve. Companies that had not found themselves scrambling to digitise operations under deadline pressure, often discovering that the transition from paper-based processes to digital systems was far more difficult than installing software. It required changing how crews recorded information, how superintendents reviewed reports, how auditors verified compliance — changing, in short, the operational culture of organisations that had done things the same way for decades.

The Rational Conservatism of the Sea

The cultural challenge of maritime digitalisation is frequently mischaracterised as resistance to change or technological ignorance. It is neither. It is the rational conservatism of professionals who operate in an environment where software failures can have lethal consequences. A chief engineer on a vessel crossing the North Atlantic in winter, managing a 50,000 horsepower engine room in sea state seven, is not interested in whether the software has an elegant user interface. He is interested in whether it will work when the ship is rolling thirty degrees and the satellite connection has been down for two days. He is interested in whether the maintenance records he entered last week will still be there after a power failure. He is interested in whether the system will tell him, accurately and reliably, which maintenance tasks are overdue and which certificates are expiring — because if it gets that wrong, his vessel may be detained at the next port, and the consequences land on him personally.

The hardest digital transformation is not in industries that lack technology. It is in industries that have operated successfully without it for centuries. The resistance is not ignorance — it is the rational conservatism of people whose mistakes can sink ships.

Editorial observation

Maritime professionals have seen software systems fail. They have seen fleet management platforms deployed with great fanfare and abandoned within a year because they did not work reliably at sea. They have seen shore-based managers impose digital reporting requirements without understanding that the crew member expected to enter data into a tablet is doing so at the end of a twelve-hour watch in an engine room where the ambient temperature exceeds 45°C. They have learned, through experience, that promises from technology companies are cheap and that the cost of a failed system is borne not by the vendor but by the crew and the operator. Their scepticism is earned.

The training challenge compounds the cultural one. Commercial vessels operate with rotating crews — officers and ratings typically serve contracts of four to six months before being relieved. A vessel's entire crew may turn over twice a year. Every new crew member must be trained on the vessel's specific systems, including its management software. If the software is complex or unintuitive, the training burden becomes a significant operational cost. Lyras understood that maritime software had to be learnable quickly by users who had limited time for training, varying levels of computer literacy, and no patience for systems that made their already demanding jobs harder. The interface had to be functional and forgiving. Error messages had to be clear. Data entry had to be efficient. The system had to respect the user's time and competence rather than demanding that the user adapt to the system's design preferences.

Building trust with maritime operators was a process that took years, not months. Lyras had an advantage that most technology founders lack: he came from inside the industry. He spoke the language — not just English or Greek, but the operational language of shipping: vessel classifications, charter party terms, P&I Club requirements, class survey schedules. He understood that a shipowner evaluating fleet management software is not evaluating features. He is evaluating risk. Will this system make my operations safer or more fragile? Will it reduce my exposure to regulatory detention or increase it? Will it survive the conditions my vessels actually operate in? These are the questions that matter. The answers had to be demonstrated, not promised — through pilot installations, through years of reliable operation, through the testimony of other operators who had used the system and found it trustworthy.

The Unsexy Innovation

Lyras represents a pattern that is systematically undervalued in technology narratives dominated by consumer apps and social platforms. He built software for one of the world's oldest, most regulated, most physically demanding industries. His customers are not users scrolling through feeds — they are chief engineers on container vessels managing machinery in engine rooms where the temperature exceeds 45°C, and fleet managers in Athens or Hamburg responsible for billions of euros in floating assets. The problems he solved are not photogenic: maintenance scheduling, regulatory compliance tracking, crew certification management, procurement workflow automation. They do not generate viral moments or venture capital excitement. They do not disrupt existing industries — they serve them, quietly and reliably, in conditions that would destroy most consumer software.

But these are the problems that keep the global economy physically moving. Every consumer product, every raw material, every energy commodity that crosses an ocean depends on the operational integrity of the vessels that carry it. When a container ship arrives safely in Rotterdam with 20,000 containers of goods from Asia, it arrives because its main engine was maintained on schedule, because its safety certificates were current, because its crew were properly qualified and certified, because its navigation equipment was surveyed and approved, because its ballast water was managed in compliance with environmental regulations. Behind each of those "because" statements is an information system — a record, a schedule, a certificate, a compliance check — that had to be accurate, current, and available when needed.

The software that manages those information systems — software built by people like Dimitris Lyras, who understood both the maritime reality and the engineering required to serve it — is infrastructure in the most literal sense. It is the informational layer beneath the physical layer of global trade. It is not glamorous. It is essential. And the fact that Lyras built it from within the industry, with the deep domain understanding that only an insider can bring, is what made it work where so many outside attempts failed. He did not try to disrupt maritime shipping. He tried to make it work better. That is the harder problem, and the more valuable one.

Sources

1. Ulysses Systems company history and product documentation — https://www.ulyssessystems.com
2. International Maritime Organisation — FAL Convention and digital shipping initiatives — https://www.imo.org/en/OurWork/Facilitation/Pages/FALConvention-default.aspx
3. UNCTAD Review of Maritime Transport, 2024 — https://unctad.org/publication/review-maritime-transport-2024
4. Lloyd's Register — digital shipping transformation reports, 2020-2024 — https://www.lr.org
5. Lyras family shipping history, Chios Maritime Museum archives
6. IMO — International Safety Management (ISM) Code — https://www.imo.org/en/OurWork/HumanElement/Pages/ISMCode.aspx
7. IMO — SOLAS Convention — https://www.imo.org/en/About/Conventions/Pages/International-Convention-for-the-Safety-of-Life-at-Sea-(SOLAS),-1974.aspx
8. IMO — MARPOL Convention — https://www.imo.org/en/About/Conventions/Pages/International-Convention-for-the-Prevention-of-Pollution-from-Ships-(MARPOL).aspx
9. Paris MOU on Port State Control — detention statistics and inspection regime — https://www.parismou.org
10. Suez Canal Authority — Ever Given incident report; Lloyd's List reporting on supply chain impact, March 2021
11. Drewry Shipping Consultants — freight rate data, 2020-2022