The story

Pear MS started as one form, in 2013.

It took twelve years to become a system. This page tells you how.

2013

The form that started it

A daily progress report. Rev twelve.

In 2013 we built a structured Daily Progress Report tool for a North Sea offshore-wind installation campaign. A digital form bound to a project database that lived on the vessel — paper replaced with one source of truth, captured at point of work. By the end of the project it was on revision twelve.

We weren't trying to invent anything. The tool replaced a paper sheet that the night-shift engineer had been filling in for years; the database replaced a folder of monthly summaries the project office stitched together at the end of every month and never looked at again.

What surprised us was what happened the moment the data started flowing into one place. We could suddenly answer questions the project leadership had been asking for years and never had a clean way to: which crews are losing the most hours to weather, broken down by shift? How long does a typical jacket installation actually take, controlling for vessel and wind? Which control measure was in place when this near-miss happened — and was the same measure missing from the three near-misses before it?

The answers were always there. They just lived in seven different folders, in nine different file formats, on five different vessels, with three different versions of the truth.

One source. One touch. Total trace. — the rule that emerged in 2013, written into Pear MS thirteen years later

2013 — 2025

Twelve years of patterns

The same problem, on thirty-one projects.

Over the next twelve years our team worked on projects across the UK, the German Bight, the Irish Sea, the Kattegat, the Dutch IJsselmeer, and — most recently — the US East Coast. Different contractors, different turbine OEMs, different regulators, different vessel fleets. The same operational problem.

Every project rebuilt the same workflow from scratch. Every project carried forward roughly 30% of the lessons from the last one and re-learned the other 70% the hard way. Every project's data went into a folder when the campaign ended.

What we started doing — first as a side project, then more seriously — was preserving those folders. Normalising them. Mapping them to one schema. By 2024 the corpus had grown to 7,315 structured operational events across 31 named installations. Big enough to spot patterns. Big enough to trust the patterns. Small enough that we could still trace any one record back to the project, the shift, and the activity it came from.

The patterns were stubborn. Risk assessments are written, then the work begins, then the conditions change, and the RA never gets revised. Incidents are investigated to "human factors" because the form has a tickbox for it. CAPA actions are closed by the same person who opened them, the same week, with no verification. Daily progress is logged against codes that were defined for a different contract and never updated.

Over twelve years we watched these patterns repeat across every project our team worked on. They were not a contractor problem. They were not a regulator problem. They were a tooling problem — the operational systems made the right thing slightly harder than the wrong thing, and over thousands of small decisions, the curve bent the wrong way.

2025 — 2026

The decision to build

Why now, and why not earlier.

For most of those twelve years we assumed someone else was building this. The IMS market is not small; the offshore-wind sector is not invisible. Surely a serious vendor was going to ship the system the corpus was quietly designing.

They didn't. What shipped instead was either (a) generic enterprise EHS suites adapted from oil & gas, with the wrong hazard taxonomy and a price point that excluded most contractors, or (b) lightweight checklist apps for the small end of the market, with no schema worth the name. The middle was empty.

By late 2025 it became clear the middle was going to stay empty unless someone built it on the basis of the data, not on the basis of a feature checklist. Pear MS is that build. Every design rule it enforces traces back to something the corpus showed us — usually multiple times, on multiple projects, over several years.

The acronym in the name is the operating procedure. People, Environment, Assets, Reputation — in that order, immune to whoever owns the company this quarter, written into the brand so it cannot be quietly reordered. The engineering rule is the same: one source, one touch, total trace.

What we are not

The honest limits.

A short page on what Pear MS is not, because the longer it stays unsaid the less you can trust what it is.

Pear MS is not

A generic EHS suite. The hazard taxonomy, control catalogues, and progress codes are calibrated to offshore-wind installation and early operations. Adapting it to other sectors would mean rebuilding the calibration, which we are not doing.
A replacement for an organisation's management system. It is structural support inside one — the IMS-shaped tool the data was always asking for, not the certificate.
A VC-backed scale-up chasing land-grab. Small team, deliberate cadence, customer-funded growth. We don't have a sales department; you'll be talking to the people building it.
A general-purpose risk-assessment library that could be deployed in any industry next week. Every assumption inside the schema is grounded in offshore-wind operational reality. Adapting it elsewhere would be honest work, not a config switch.

If you're looking for one of the things on that list, we're not the right vendor and we'd rather tell you in the first email than the third meeting.

If the patterns above sound familiar, let's talk.

We'd rather hear about the operational problem you're stuck on than recite our feature list. Tell us your sector, your projects, and the question your current system can't answer — we'll tell you whether Pear MS is the right shape for the problem.

Start a conversation or read the methodology → The Calibration Corpus