Seastead Project · Safety Systems

Smartphone Man-Overboard Detection:
Feasibility Review & Design Notes

A phone-heartbeat MOB watchdog for the trimaran seastead — and a gift to every other boat.

Status: concept review · All numeric estimates flagged where uncertain

1 · Direct answers to your questions

Your question	Short answer
How many people die per year from man-overboard events?	In the US alone, falls overboard kill roughly 150–260 recreational boaters per year (about a quarter to a third of all recreational boating deaths). Including commercial fishing and worldwide waters, the toll is plausibly well over 1,000/year. See §2.
Would most phones survive a day with this app running?	Yes — if the design is BLE-first, no phone-side GPS. Expect roughly 2–5 % battery per day of added drain. Wi-Fi-polling-every-second designs would burn 10–25 %/day. See §6.
Can a user set “never put this app to sleep”?	Yes on Android (battery-optimization exemption + foreground service; OEM-specific toggles too). Partially on iOS — no user override, but background modes keep a bonded BLE app alive reliably. See §7.
Could Claude Code / Cursor write the app and server?	Agree — the “hello world” pain you remember from Java ME is gone. An MVP is a 1–2 week job; a trustworthy v1.0 is 1–2 months part-time, dominated by real-device background-behavior testing and on-the-water RF tuning, not by typing code. See §12.
Would most family yachts have a computer able to run the server?	Yes — chartplotters are closed, but virtually every cruising boat has a laptop/tablet, and a $60 Raspberry Pi is ideal. Alarm output is trivial (relay + horn). Auto-stop via the autopilot is the only non-trivial retrofit on legacy boats; alarm-only mode is still valuable. See §11.
Has anyone done this already?	Close cousins exist — Exposure OLAS, Sea-Tags, MOBi-lert, Fell Marine MOB+, Autotether (all use dedicated tags, not phones); AIS MOB beacons and PLBs (manual/auto-activating distress radios). A mature open-source, phone-based, auto-return system appears to be an unfilled niche. See §3.

2 · How many die from man-overboard events?

Precise global numbers don’t exist; different agencies count differently. Best available anchors:

USCG Recreational Boating Statistics (annual): “falls overboard” is consistently one of the top two fatal accident types, alongside capsizing. Recent years show roughly 150–260 deaths/year from falls overboard in US recreational boating — on the order of a quarter to a third of all recreational boating fatalities. Verify against the latest annual report.
UK MAIB analyses: a large majority of MOB casualties in their studies were never recovered, and solo sailors are heavily over-represented among fatalities. Time-to-recovery is the dominant survival factor.
Cruising Club of America safety-at-sea reviews: historically consistent with your “~50% fatality” intuition for offshore MOB events — many victims are never found.
Commercial fishing: MOB is a leading cause of occupational drowning worldwide (ILO/IMO have flagged it for decades). Adding this, the global figure is plausibly 1,000+/year, but no single clean statistic exists.

Treat all figures as order-of-magnitude. Even the low end justifies a cheap, universal mitigation.

Why recovery fails (and why your design attacks the right variables):

Detection delay: on many boats nobody notices for 10+ minutes.
Turn-back delay: a displacement sailboat takes minutes to tack/gybe back and often loses the datum.
Search error: without a marked datum, the search area grows quadratically with delay.
Cold shock / swim failure: in water <15 °C, incapacitation can occur in minutes (Caribbean waters are kinder — hours, not minutes).

Your seastead removes three of these four: near-zero heel (fewer falls), instant straight-line stop (no Williamson turn), and a computer-recorded 1 Hz track (perfect datum). The phone system closes the last gap: detection latency of seconds instead of minutes.

Latency budget for your seastead (concrete numbers):

At 8 knots the vessel covers ≈ 4.1 m/s. Detection at 3 s + stop command at 6 s ⇒ stop point ≈ 25 m past the datum.
Backing/reversing to the datum at ~4 knots adds ~12 s. On-scene in ~20–30 s total.
A person drifting at 0.5–1.5 kn (wind + current) offsets only ~10–25 m in that window — well within visual/ladder range, especially with the dinghy launched.

This is dramatically better than a typical yacht MOB timeline measured in minutes to hours.

3 · Prior art & existing products

System	Type	Auto-detect?	Approx. cost	Notes / limitation
Exposure OLAS (Core / Guardian / T-2)	BLE tags + hub app	Yes — out-of-range or submersion	$150–500 + tags	Closest commercial cousin of your idea. Guardian can cut the engine. Uses dedicated tags, not phones; closed source.
Sea-Tags	Phone app + BLE wristbands	Yes	~$100–200/tag	Racing-oriented; phone is the base station. Again: tags, not phones-as-transmitters.
MOBi-lert	Superyacht crew bands + base	Yes	$$$$	Legacy superyacht system; proves the concept at scale but expensive and proprietary.
Fell Marine MOB+	Wireless kill-switch hub + fob	Yes — stops engine	~$300–400	Replaces the physical kill-switch lanyard. Small-boat focused.
Autotether	Wearable fobs + base	Yes — submersion or range	~$300–500	Alarm + optional engine shutoff. Same architecture as yours with fobs.
AIS MOB beacons (Ocean Signal MOB1, ACR, Kannad)	Self-activating radio (AIS + DSC)	Yes on inflation/manual	$300–400 each	Alerts all nearby AIS vessels + your VHF. Gold standard for offshore; requires a life jacket to be effective.
PLBs / EPIRBs (406 MHz)	Satellite distress	Manual (some auto)	$300–800	Global SAR-grade. Not a real-time “stop the boat” system — it summons rescue services.
Chartplotter MOB button (Garmin/Raymarine/B&G)	Software function	No — someone must press it	Free (built in)	Marks datum and steers a return course. Useless if the MOB is unwitnessed or crew is solo/panicked.
Smartwatches (Apple Watch fall detection + satellite SOS, Garmin incident detection)	Consumer wearable	Fall yes; submersion degrades touchscreens	$300–800	Nice complement; depends on connectivity and wearer configuration.
Voyage-check-in apps (e.g., SafeTrx)	Phone app + shore contact	No — trip-level only	Free/$	Alerts shore contacts if you miss check-ins. Minutes-to-hours granularity, not seconds.

The gap you’ve spotted is real: every auto-detecting product above either (a) uses dedicated hardware tags/beacons costing $100–400 per person, or (b) is a closed proprietary ecosystem. Nobody ships a polished open-source, phone-only, heartbeat-based MOB watchdog with automatic stop-and-return. Phones are already in pockets, already have BLE/Wi-Fi, and the marginal hardware cost is zero. This is a genuinely worthwhile open-source project — and building it before the seastead exists is the right sequencing, because it benefits every boat, not just yours.

Important framing: a phone system is a coastal / day-operations layer. It does not replace a 406 MHz EPIRB offshore, nor an AIS MOB beacon clipped to a life jacket. Phones die, get left below, and sink. Position it as “makes everyday operations dramatically safer,” not “replaces SAR-grade equipment.”

4 · Why your concept is sound

Base records the track, phones stay dumb. Correct division of labor. The phone needs no GPS (the biggest battery hog), no screen interaction, no user skill. It only has to say “still here” once per second.
Submersion = instant, unambiguous signal loss. You’re right that seawater is effectively opaque at 2.4 GHz — attenuation is on the order of tens of dB per centimeter. In practice the link often dies before full submersion, because a wet antenna near the surface detunes badly. This gives you a sharp, low-false-positive trigger that pure range-based systems lack.
Graceful degradation ladder. Miss → ping → alarm → stop → return is exactly the right escalation. Two-sided tolerance (don’t panic on one lost packet, don’t dawdle on three) is the whole game.
Zero-G pre-trigger is clever. Free-fall (>200–400 ms of ≈0 g) is nearly impossible to fake accidentally while walking a deck. Using it to pre-arm the alarm state — rather than to declare MOB outright — is the right conservative design, because a dropped phone also produces a zero-G event.
Solo-sailor case covered. Auto-stop + auto-return with no human in the loop is the feature that saves the singlehander, and almost no commercial product does it autonomously (OLAS Guardian cuts the engine; few systems navigate back).
Ladders + grating walkway + doors-with-phone-check round out the survival chain: detect fast, arrive fast, climb out fast.

5 · Radio strategy: BLE vs Wi-Fi vs water

Recommended architecture: BLE-primary, Wi-Fi fallback, no phone GPS

Primary: BLE connection, phone → base, 1 Hz notify. A bonded BLE connection survives screen-off far better than Wi-Fi association on both platforms. Tiny packets (timestamp + counter + HMAC, ~20 bytes) at 1 Hz are nearly free energetically.
Who scans? Prefer base scans / phone advertises-or-connects. Continuous BLE scanning on the phone is the expensive role; being a connected peripheral (or central to a base that always advertises) is cheap. Pick one topology and stick to it.
Fallback: Wi-Fi at reduced rate. If BLE drops (interference, driver quirk), fall back to a UDP heartbeat every 5 s over Wi-Fi. Accept the higher drain only as a degraded mode, and surface it in the app status (“degraded — BLE unavailable”).
No GPS on the phone in normal operation. The base knows vessel position at 1 Hz. The phone’s contribution to localization is (a) which door it exited, and (b) the zero-G timestamp. Enable phone GPS only after an alarm, and only if the phone might still be afloat (see §10).

Physics notes worth exploiting

Seawater attenuation at 2.4 GHz: roughly 300–1000 dB/m — i.e., a few centimeters of seawater ends the link completely. Fresh water is somewhat less brutal but still fatal to the link within decimeters. Your “submersion triggers the break instantly” premise is correct.
Body absorption: a phone in a front pocket already loses 10–20 dB through the body; swimming posture (phone trapped against chest underwater) kills the link even before deep submersion. Good for detection sensitivity.
The floating-phone bonus: if crew carry phones in a floating waterproof pouch (a $15 accessory), the phone keeps transmitting after the fall. Then the base can RSSI-home toward it, and the zero-G + continued-heartbeat pattern distinguishes “person in water, phone floating” from “phone sank.” Strongly recommend making the pouch part of the protocol culture.
Metal-wall shadowing (specific to your seastead): an enclosed aluminum-skinned living area is a partial Faraday cage. Link quality will change abruptly at doorways. Place two BLE antennas (USB dongles) high, port and starboard, with antenna-diversity selection in the base software, and map the RF shadows during commissioning. This is a bigger real-world factor than any protocol detail.
Coexistence: marina Wi-Fi congestion, your own Starlink router, and microwave ovens all live at 2.4 GHz. BLE’s adaptive frequency hopping handles this well; fixed-channel Wi-Fi heartbeats do not. Another reason BLE is primary.

6 · Battery-life impact

Estimates assume a modern phone with a ~4,500 mAh battery in decent health, screen off, app in background. Real devices vary ±2×; treat as planning numbers and verify on your actual fleet of phones.

Activity	Typical avg. current	% battery / day	Verdict
BLE connected, notify 1 Hz (screen off)	~1–3 mA	~1–2 %	Negligible
BLE advertise-only (alt. topology)	<1 mA	<1 %	Negligible
BLE continuous scanning (avoid on phone)	~20–60 mA	~10–30 %	Avoid
Wi-Fi associated, screen off, idle	~15–40 mA	~8–20 %	Costly
Wi-Fi UDP poll 1 Hz	~20–50 mA	~10–25 %	Too costly as primary
Wi-Fi UDP poll 0.2 Hz (fallback mode)	~8–20 mA	~4–10 %	Acceptable fallback
GPS 1 Hz continuous	~25–50 mA	~13–27 %	Skip — base has the track
Accelerometer 50–100 Hz, gated (only when outside)	~2–8 mA	~1–4 %	Fine when gated

Bottom line

BLE-first design: ~2–5 %/day added drain. Virtually any phone finishes the day comfortably. Older phones (battery health <80 %) still make it; enable the charge-nag below ~70 %.
Worst realistic mixed day (BLE flapping → Wi-Fi fallback + high-rate accel all afternoon): ~10–15 %. Still usually fine, but the app should display live drain attribution so users trust it.
Kill the myths early: the expensive things are scanning, GPS, and screen-on Wi-Fi chatter. A 1 Hz connected-BLE heartbeat is none of those.
Charge discipline: nag at 70 %, warn at 40 %, and have the base flag any crew phone below 30 % at morning muster (“red phone list”). A dead phone should be treated culturally like no life jacket.

7 · Keeping the app alive (doze & OEM killers)

Android — yes, the user controls this

Foreground service with a persistent notification (“MOB Guard: Protected ✓”) is the single most important mechanism. It exempts the app from Doze/App-Standby while shown.
User setting: Settings → Apps → [app] → Battery → Unrestricted (stock Android). Programmatically, request exemption from battery optimization (REQUEST_IGNORE_BATTERY_OPTIMIZATIONS intent) and walk the user through it on first run.
OEM killers are the real enemy: Samsung (Sleeping apps / Deep sleeping apps), Xiaomi/MIUI (Autostart + “No restrictions”), Huawei, OnePlus all ship extra layers. Ship an in-app “setup doctor” that detects the OEM and links to the exact toggle. The Don’t kill my app website catalogs these per vendor — use it as your checklist.
BLE bonds persist across reboots; a killed-and-restarted app can reconnect to a bonded base without user interaction.

iOS — no user override, but background modes suffice

iOS suspends apps aggressively, but: an app using the bluetooth-central or bluetooth-peripheral background mode, with a bonded/known peripheral, gets re-awakened on connection events and can maintain a connection indefinitely in practice. State restoration (bluetooth-central + restore identifier) lets iOS relaunch your app into the background when BLE events occur.
Location background mode would also work but burns more power and invites App Store scrutiny; prefer BLE-only.
Consequence: iOS phones should be the connected-central to an always-advertising base; Android can do either. Test on the oldest iOS version you intend to support.

Setup-doctor checklist (what the app should verify on first run)

Battery optimization exempted (Android) / Background App Refresh on (iOS)
Bluetooth permission granted; Nearby-devices permission (Android 12+)
Notifications enabled (so the persistent status + alarms are visible)
OEM-specific autostart/battery toggles (per-vendor deep links)
Live end-to-end test: app ↔ base round-trip < 1 s, displayed as “Protected ✓”
Battery-health readout and charge-nag threshold acknowledged by user

8 · Timing, false alarms & the state machine

Your instinct (alarm at 3 s, maneuver at 6 s) is sound. Formalize it with retries and hysteresis so one lost packet never escalates, but three consecutive losses always do:

NORMAL ──heartbeat ≤1.2s──► NORMAL
   │
   └─ miss #1 ──► SUSPECT  (base fires BLE ping requests, 5×/s)
                     │ reply received ──► NORMAL (log "glitch")
                     │ miss #2 ──► SUSPECT+ (ping faster, prep alarm)
                     │              │ reply ──► NORMAL
                     │              │ miss #3 (t≈3s) ──► ALARM
ALARM: sound horn + strobe, freeze datum, arm maneuver
   │ t≈6s ──► MANEUVER: stop, reverse to datum, hold, expanding search
   │
RECOVERED: requires PHYSICAL button at helm AND app confirm by that user
           (prevents a stray tap from silencing a real emergency)

ZERO-G fast path: phone free-fall event ⇒ base immediately enters
SUSPECT+ for that user (even if heartbeats still arriving) — because
the next thing that happens to a fallen phone is submersion.

Parameter	Suggested value	Rationale
Heartbeat period	1 s	Fast detection; negligible battery (§6)
Alarm after	3 consecutive misses (~3 s)	Tolerates 2 lost packets; still fast
Maneuver after	6 s from first miss	≈25 m run past datum at 8 kn — acceptable
Ping burst during suspect	5 pings/s for up to 3 s	Distinguishes glitch from gone
Glitch hysteresis	Log, don’t alarm	Target <1 false alarm/month in service
Reset	Physical button + app confirm	No accidental resets; deliberate action
Nightly self-test	All phones, 21:00	Catches dead batteries before bedtime
High-rate accel gating	Arms on door-open / exterior entry	Saves battery; zero-G only meaningful outside

False-positive sources to engineer against: dropping a phone on deck (zero-G + impact — but heartbeat continues, so no alarm), jumping in deliberately for a swim (add a 60-second “swimming” mode toggle in the app), RF black spots behind masts/engines (map them; add a repeater dongle if needed), and microwave-oven bursts (BLE hopping shrugs these off).

9 · Identity, MAC randomization & security

MAC randomization will bite you. Modern phones rotate BLE addresses. Never identify crew by MAC. Instead: use bonded connections (IRK-resolved identity), or embed a crew ID + rolling counter in the payload.
Authenticate heartbeats. A 4-byte HMAC per message prevents anyone (or any misbehaving app) from spoofing “all present.” Sequence numbers reject replays. This is cheap insurance, not paranoia.
Crew roster management: pairing ceremony at muster (“tap phone to base NFC/QR”), revocation when someone leaves the boat. Keep it under 30 seconds per person or people won’t do it.
Two-seastead rafting: bases federate — either unit can see all crew; alarms annunciate on both; the walkway-crossing handoff is just two bases sharing one heartbeat stream. Specify this in the protocol from day one.
Privacy: location/heartbeats stay on the boat (LAN only) by default; cloud sync strictly opt-in. People will sabotage a system they feel surveils them.

10 · Localization & the recovery maneuver

Datum = last good heartbeat position from the base’s 1 Hz track, refined by the zero-G timestamp if available. Error bars: ±(distance traveled in 1–2 s) ≈ ±4–8 m. Excellent.
Person drift: wind pushes the torso, current pushes everything; net 0.5–1.5 kn typically. After your 20–30 s on-scene time the offset is small — but if the initial search fails, transition to a down-drift expanding-square search immediately, not a random wander.
Mark the datum physically. Software datum is invisible to a panicked swimmer. Near-term: crew throws a buoyant marker. Later (your build): a solenoid-dropped dan buoy with strobe that releases automatically on MANEUVER entry — cheap, transformative, and unique to a custom vessel like yours.
If the phone floats (waterproof pouch culture, §5): keep listening for its heartbeat and home on RSSI gradient. A floating phone is a homing beacon you already own.
Recovery hardware: your stern ladders + low freeboard foil decks are genuinely good. Add a throwing line bag at each door and a reach pole. Rehearse the drill monthly — the system buys seconds; the drill converts them into lives.
Night: alarm must include a strobe + deck floods, not just a horn. Horns get slept through; also, the victim can’t hear a horn, but they can see a lit boat coming back for them.

11 · Running the server on ordinary yachts

Base hardware	Cost	Fitness
Raspberry Pi 4/5 (built-in BLE) + USB BT dongle ×2 for diversity	$80–120	Ideal — 24/7, GPIO relay for horn, CAN/NMEA hats available
Old laptop / Mac mini / mini-PC	$0 (already aboard)	Great — add a $10 USB BLE dongle; audio-out drives a siren
iPad/Android tablet	$0	Partial — can run the app-side, weak as 24/7 server
Chartplotter / MFD	—	No — closed platforms; can’t host custom code

Outputs, easiest to hardest

Local alarm (horn/strobe via relay or powered siren): trivial, do this first. Even alarm-only saves lives versus nothing.
Annunciation everywhere: push to crew phones (LAN notification), cockpit display, smart-speaker announcement.
Autopilot auto-stop (retrofit boats): the hard part. Options: NMEA 2000 command if the pilot supports remote “standby”; a relay into the drive’s clutch/stop input; or worst case, alarm-only with a laminated “MOB = hit STANDBY” placard. Still valuable.
Your seastead: trivial by comparison — your own thruster controllers take a STOP/REVERSE command directly from the base over your internal network. Design the thruster API with a reserved, highest-priority MOB channel from day one.

12 · Building it with AI tools

You’re right about the changed economics

The Java-ME-era pain (signed builds, obfuscation, device matrices, no Stack Overflow) is gone. Today: install Android Studio, ask Claude Code / Cursor / Copilot for a foreground-service BLE skeleton, and you have a working heartbeat demo in an afternoon. What remains genuinely hard is not typing code — it’s the last 20 %: background-execution quirks across OEMs, RF behavior at sea, and the discipline of on-water testing.

Recommended stack

Layer	Choice	Why
Android app	Kotlin, foreground service, android.bluetooth APIs	Most permissive background model; biggest installed base on boats
iOS app	Swift, bluetooth-central background mode + state restoration	Only reliable way to keep BLE alive on iOS
Cross-platform shortcut	Flutter + flutter_reactive_ble	Viable for MVP; expect to drop to native for background edge cases
Server	Python (asyncio + bleak) or Node (noble) on Raspberry Pi	AI tools generate this flawlessly; bleak handles multi-adapter diversity
Protocol	BLE GATT notify, 20-byte frames: ID ‖ seq ‖ flags ‖ HMAC	Simple, auditable, versionable
Alarm I/O	GPIO relay → 12 V horn + strobe; MQTT/LAN annunciation	Standard Pi fare
Debugging	nRF52 Sniffer dongle + Wireshark; Android btsnoop	You cannot fix what you can’t see on-air

Realistic effort (part-time, AI-assisted)

Weekend: protocol draft + Pi server + two Android phones + horn. End-to-end “stop the fake boat” demo.
Weeks 1–2: hardened Android app (setup doctor, charge nags, swimming mode, logging).
Weeks 3–5: iOS app + TestFlight; OEM battery-killer matrix testing (borrow friends’ Samsungs/Xiaomis).
Weeks 6–8: on-water trials on any friendly boat: packet-loss stats by sea state, RF shadow maps, false-alarm tuning, drill scripts.
Ongoing: OS updates will occasionally break background behavior. Budget a maintenance day per quarter. This is the true cost of the project — say so openly in the README.

Honest caveats for the README: (1) an app that must never sleep is fighting its own OS vendor — expect whack-a-mole; (2) iOS review may question background-BLE apps — frame it clearly as a safety utility; (3) field RF is messier than any bench; the sea-trial phase is not optional; (4) open-source safety software needs a prominent “not certified, complement — don’t replace — PLB/EPIRB” disclaimer.

13 · Risk register / gotchas checklist

#	Gotcha	Mitigation
1	Android Doze / App Standby suspends heartbeats	Foreground service + battery-optimization exemption + setup doctor
2	OEM task killers (Samsung/Xiaomi/Huawei)	Per-vendor setup screens; test matrix; “Don’t kill my app” catalog
3	iOS background limits	Bonded BLE + state restoration; iOS phones act as central
4	MAC randomization breaks crew identity	Bonding / payload IDs + HMAC; never trust addresses
5	Wi-Fi disassociates when screen off	BLE primary; Wi-Fi only as reduced-rate fallback
6	Continuous BLE scanning drains phones	Base scans; phone connects/advertises only
7	GPS on phone would dominate battery	Base owns positioning; phone GPS only post-alarm
8	Metal living-area walls shadow RF at doorways	Dual antennas + diversity; commission-time RF map
9	2.4 GHz congestion (marina Wi-Fi, Starlink, microwaves)	BLE adaptive hopping; schedule defrost cycles 🙂
10	Phone sinks → no homing signal	Floating waterproof pouch culture; BLE-tag fallback on PFDs
11	Dead phone = silent hole in the shield	Charge nags, morning red-list, optional door sensor (§ below)
12	False-alarm fatigue kills the system socially	Hysteresis + pings; log glitch rate; target <1 false alarm/month
13	Accidental reset silences a real event	Physical button + app double-confirm
14	Solo operator unconscious/unreachable	Fully autonomous stop-and-return; no human confirm needed to start
15	Swimmer mode forgotten ON	Auto-expire after 10 min; loud countdown; base annunciation
16	Alarm inaudible underway / asleep	Horn + strobe + deck floods + crew-phone push cascade
17	Overtrust: “we have an app, skip the EPIRB”	Explicit positioning as a complement; drills include PLB use
18	Un-tested code paths rot silently	Nightly self-test (base↔every phone), logged and reviewed
19	Two-seastead rafting confusion	Federated bases specified in protocol v1
20	Privacy backlash from crew	Logs stay on-boat by default; opt-in cloud only

Optional hardware add-ons (cheap, high value)

Door sentinel (~$25): reed switch + ESP32 at each door; alarms if a door opens with zero registered phones outside. Doubles as the trigger to arm high-rate accelerometers. You suggested this — it’s worth doing despite being “extra hardware,” because it catches the dead-phone case at the exact moment of exposure.
PFD BLE tags (~$30): same base listens for dumb iBeacon-style tags as a phone-independent backstop.
Auto dan-buoy dropper: solenoid release on MANEUVER entry (custom-build advantage).

14 · Recommended roadmap

Phase 0 — Spec (now): write the protocol doc (frame layout, state machine, timing constants, security model). One weekend. This document becomes the AI prompts’ ground truth.
Phase 1 — Bench MVP (weeks 1–2): Pi base + 2 Android phones + relay horn. Prove 1 Hz heartbeats, 3-miss alarm, 6-s maneuver command to a mock thruster controller.
Phase 2 — Any-boat trials (weeks 3–6): borrow a friend’s yacht. Collect packet-loss statistics, map RF shadows, tune constants, publish the false-alarm rate honestly.
Phase 3 — Harden & widen (months 2–3): iOS app, setup doctor, charge-nag economy, nightly self-tests, open-source release with disclaimers. Seed it with 3–5 volunteer boats.
Phase 4 — Seastead integration (with the build): dual antennas, door sentinels, auto dan-buoy, thruster MOB priority channel, federated twin-seastead bases, monthly drills baked into the operating manual.

Strategic upside: shipping this as a free open-source project before the first seastead exists builds the community, hardens the software on dozens of hulls, and creates goodwill no marketing budget could buy. It is also exactly the kind of project whose development (AI-assisted, commodity hardware, zero per-unit licensing) matches the seastead ethos.

15 · Sources & further reading

USCG Recreational Boating Statistics (annual) — uscgboating.org
UK MAIB accident reports & MOB analyses — gov.uk/maib
RNLI research on cold-water shock & flotation — rnli.org
Cruising Club of America, “Safety at Sea” casualty studies
ILO / IMO guidance on fisher safety (MOB in commercial fleets)
Exposure OLAS — exposureolas.com · Sea-Tags — seatags.com
Ocean Signal MOB1 — oceansignal.com · ACR — acrartex.com
Fell Marine MOB+ — fellmarine.com · Autotether — autotether.com
Android Doze & foreground services — developer.android.com
iOS background modes / state restoration — developer.apple.com
“Don’t kill my app!” OEM battery-killer catalog — dontkillmyapp.com

Fatality figures in §2 are order-of-magnitude syntheses of the sources above; consult the latest annual reports for precise current numbers before publishing claims.