Case study · 2024–26

Tidewater

Scheduling for marine service yards

Tidewater — summary

Problem
Boat yards were booking haul-outs on whiteboards and losing a day a week to double bookings.
Role
Lead developer
Years
2024–26
Stack
TypeScript · Svelte · Node · Postgres · AWS
Double bookings
down 80%
Yards using it
41
Median page load
0.9 s on 3G

Tidewater.md

This case study is sample content. Replace it with verified work before production deployment.

The problem

The schedule lived in several places at once: a whiteboard, a spreadsheet, and the heads of people who had worked at the yard for years. A booking could look valid in isolation while still asking too much of the lift, the tide window, or the available crew.

The approach

I started with the constraint model, not the calendar interface. We wrote down which conflicts were impossible, which were warnings, and which needed a human decision. The interface then exposed those rules in plain language instead of hiding them behind a generic red state.

The first release kept the whiteboard visible beside the screen. That made the transition reversible and gave us a clean way to compare the old plan with the new one during real work.

The result

The shared schedule reduced double bookings and made capacity visible earlier. The useful outcome was not that the whiteboard disappeared. It was that the morning meeting stopped being an exercise in reconstructing yesterday.

Make the hard choice visible.

A durable decision leaves enough context for the next person to understand the tradeoff, not merely the outcome.

Go to

↑ ↓ moveEnter openEsc close