Widget abstraction.
A clean instrument package — instruments-core
plus per-theme packages — built on a 14-token theming system with
three base themes (sci-fi, monochrome, e-ink). Spec is written.
Plan-writing is next.
Roadmap
What's shipped. What's next. What's later.
32 degrees North runs on my timeline, not a VC's quarterly milestones. I ship when it's right — when it works properly and I'd actually use it on my own boat.
This is the honest picture of where things are. Follow along on GitHub if you want the commit-by-commit version.
Now
What's working today.
These apps are built, running, and in daily use. The platform underneath them — the hub OS, the cloud services, the shared data layer — is also live.
Chartplotter
Live nautical charts, AIS vessel tracking
Passage planner
Route planning with waypoints and weather integration
Systems planning
Batteries, solar, alternators, loads
Logbook
Intelligent log using passage and instrument data
VHF trainer
Radio procedure practice with AI coastguard agents
Knowledge base
Research docs, architecture, reference material
RYA course cards
Day Skipper, VHF/SRC, Competent Crew cheat sheets
The hub OS is running on a Mac mini with a standard NMEA-2000 gateway. The cloud services — sync, weather data, AI gateway — are live and used daily.
Next
Within reach.
The next set of apps that are already being built, plus the four internal projects that complete the 32°N design and naming rebrand.
Apps coming next
The 32°N rebrand — four internal projects
The platform currently ships under the working name RNA8. These four projects complete the move to 32°N — in this order, because each one depends on the one before it.
Theme system and picker.
The user-facing theme picker — choose and preview an instrument theme per screen or per boat. Builds directly on the token architecture from project C. No picker without the tokens.
Sub-project D · depends on CVisual rebrand of the live site.
Swap the current marketing site over to the 32°N visual language: Geist, the paper palette, coral accent. This is the public-facing part of the rebrand. Can't go live before the theme system is stable, because the site showcases the instrument themes.
Sub-project B · depends on DNaming rebrand.
Rename @32n/*
to @32n/*
across the whole repo, then swap the domain from 32north.ai to
32north.ai. Last in the sequence — the lowest design risk, but the
highest merge-conflict surface. You don't want to do this twice.
Later
When it's right.
These are the things I'm thinking about but haven't started yet — either because something else has to come first, or because I haven't found the right approach. I'd rather not ship them than ship them half-baked.
- Anchor watch — drag detection, position alerts, customisable alarm radius. The safety case has to be right before this ships.
- Marine security scanner — progressive testing of connected equipment, configurable depth, CLI first. My background, done properly.
- AI vision — camera-based collision detection and watchkeeping assist. Needs reliable hardware before it's useful.
- Automation — rule-based boat automation (if bilge sensor, then alert). Has to be safe and auditable before it touches anything on a live boat.
- Mediterranean chart coverage — preferred cruising ground. I want the charts to be good before they're available, not the other way around.
- Tide engine — harmonic tide calculations for passage planning. The maths is done; the interface needs work.
- Android version — the platform is web-based, so Android support is mostly a browser-compatibility and packaging pass. Not a rebuild.
- Purpose-built hub hardware — a small, fanless, sealed box that runs 32°N OS out of the box, purpose-designed for the marine environment. The Mac mini works; this would be better.
- Community theme marketplace — once the theme token system is stable, anyone can publish a theme as a TOML file. Post-1.0.
How I decide what ships when
The principles behind the priorities.
I'm one person, building something I want on my own boat. That shapes every call about what comes next.
Security is part of the architecture, not an afterthought.
I spent a decade in software supply chain security. I'm not going to ship a marine platform that someone can walk onto with a Flipper Zero. If something can't be done securely yet, it waits.
I ship narrow and correct before I ship wide.
A chartplotter that works reliably is better than ten apps that each work sometimes. The v1 apps are the ones I use myself, proving they're right before I expand the catalogue.
No premium tiers, ever.
AGPL-3.0 is a structural commitment, not a marketing line. Nothing I build will ever be paywalled, and I won't add a commercial licensing exception that lets someone close the code.
It has to work with the boat you already have.
Two pieces of standard, off-the-shelf hardware. Not a proprietary gateway or a custom sensor network. The install should take an afternoon, not a shipyard visit.
I don't build from market research.
I build what I'd want. If I wanted a feature and couldn't find a good version of it, that's a better signal than any survey. The VHF trainer, the electrical planner, the security scanner — all started that way.
The platform handles the unglamorous parts so apps don't have to.
Auth, notifications, audit log, data sync, AI access — all platform services. An app developer (or future me writing a new app) shouldn't have to wire those up from scratch. That's the point of building a platform instead of a collection of tools.
Follow along
Stay in the loop.
The best way to follow what's shipping is to watch the repo on GitHub. Everything is in the open — commits, issues, specs, discussions.