In 2016, we started building a shipyard software company alongside our consulting practice.

When our founder, Jonathan Malanche, launched Oxalis in 2016, we were a technology consultancy drawn to hard problems, regulated industries, and organizations everyone else found too difficult to serve. We didn’t have a vertical focus and a predetermined market. We had a belief that if we showed up with real rigor and stayed close to the work, we could figure out almost anything.

A maritime practice emerged, and we kept running into the same problem. The processes that drive a Navy availability, condition-found reports, change orders, test and inspection plans, ran on paper and institutional knowledge. It was slow, error-prone, and invisible to leadership until something went wrong. We ran a build-versus-buy analysis. Nothing compliant existed. So we built OSRS, the Oxalis Ship Repair System.

We built it on a server that gave us an enterprise-grade workflow engine without building one from scratch. It was not elegant, but it was effective. Shipyards started asking for it.

We kept building, and our presence in the yards deepened. We learned ship repair by walking the yard, sitting in the contractor-customer meetings, and watching how information moves, and stops moving, across a yard in the middle of an availability. The terminology, the standards, NAVSEA requirements, the way the commercial estimating cycle runs, none of it maps cleanly to generic software.

Out of that work came OAE, Oxalis Advanced Estimation. Estimating was still broken. A yard’s bid either reflected reality or it found out at execution what it should have known at proposal. We built OAE because nothing purpose-built existed. It went into production and has been running availabilities ever since. Yards still run it today.

What we learned from OAE, and from years of running OSRS, is that the real problem in ship repair is not any one part of the lifecycle. It is the handoffs between parts. Estimation runs in one system, execution in another. The data that should inform the next bid, what you found when you opened the hull, the actual labor hours, what changed, gets lost between project close and the next award. Every yard re-learning lessons it already paid to learn.

That is the problem YardOS was built to solve.

YardOS is the product that OSRS and OAE were pointing toward. A unified platform for the full lifecycle of ship building and repair, including estimation, proposal, execution, warranty, sustainment. A system that captures intent and decisions at every stage, not just outputs. AI embedded in the workflows where it actually helps with safety agents monitoring against NAVSEA standards, leadership agents translating plan-of-the-day data into role-specific visibility, research agents surfacing lessons from past availabilities before you need them. Mobile-first, because the people who need this system are not sitting at desks.

We are launching YardOS in 2026.

The maritime industrial base is under pressure it has not seen in decades. The Navy needs ships sustained faster. Yards are running the same workforce across new build and repair, under tighter schedules and evolving compliance. The organizations that come through it well are the ones that stop losing institutional knowledge at every project boundary.

We have been building toward this for ten years. This year, that work becomes YardOS. It starts with YardOS Estimation: the OAE yards already run, enhanced and carried into YardOS.

If you bid availabilities, run estimating for a yard, or are tired of losing institutional knowledge between proposal and execution, start with YardOS Estimation.