The first three weeks of HurricaneWise

Why a hurricane tracker

I live where hurricanes go, and I wanted an easier way to read the official NHC and NOAA information for where I am. So HurricaneWise tracks eleven forecast models (including the official forecast and two consensus aids) and uses Claude to explain them in plain English. It doesn't make a forecast of its own. It shows where the models agree and where they split, and what that might mean at your location, and it tries to say it calmly.

I also wanted to find out if I could run a public product by myself with AI doing a lot of the work. Besides the code, that meant monitoring, incidents, legal copy and a bill that still makes sense after launch. The data can go stale at any hour, and I needed to know when it did without sitting in front of a terminal all day.

The first working version took about three weeks (May 30 to June 21, 2026) and 184 commits, 91 of them fixes.

The 91 fixes

The AI produced code that ran. It had not yet spent weeks against a live feed I don't control, so there was a lot it hadn't seen.

Most of the fixes were for things I hadn't coded for: a storm that dissipated but stayed on the page, a health check that said green while the data behind it went stale, a cron schedule that was only best-effort, and a JSON response cut off at exactly the wrong byte. None of those showed up until it had been running a while against a source I don't control. The phantom storm goes through five of them in detail.

When the first version costs almost nothing, you reach those problems sooner and spend most of your time on them. The constitution now requires a failing test before any bug fix.

What the AI set up

On every infrastructure project I've done, setting up a new service ate days. I'd spend two days in a vendor's docs figuring out which keys its agent wants in a config file, and then an afternoon working out what the free tier actually counts. With seven services here that would have been weeks, and a different specialty every time.

On this one I handed that part to the AI. I'll probably never learn the Grafana agent's config language, and as far as I can tell I don't need to. I told it what I wanted watched (the pipeline, the host, the logs, and the public site from outside). It read the docs, wrote the agent config, set up the synthetic checks, and came back with the free-tier ceilings and where we'd land against them. It also found a few features I wouldn't have known to ask for.

I did the same for the scheduled services on the server, the zero-trust check on the internal dashboard, the vault wiring for secrets and a parser for NOAA's fixed-width storm format. The AI handled the setup; I kept the decisions about what to watch and which limits to enforce.

I did the rest myself. I decided what was worth watching and set every alert threshold, including which checks run every 60 seconds and which every 15 minutes. More than once I caught a config before it shipped that would have burned through a free tier.

Jobs that weren't code

I also used it on the storm explanation, the reliability checks, costs, disclaimers and the mobile page. Same model every time, but each job needed a different brief and a different way of checking the result. For a status notice I'd ask what a worried visitor could still use. For an engineering report I wanted a likely cause and a link to the logs.

So I had to learn enough about each discipline to spot a weak answer, and how hard I looked depended on what a miss would cost. What my job looks like now is about what that did to my day.

Where it is now

By mid-October 2026 the repo had 357 commits, 156 tagged releases (latest v2.6.40) and about 2,200 automated tests, up from 312 commits, 125 releases and about 1,880 tests in late July. I wrote my operating rules down in a versioned constitution, ratified on 26 July 2026 after an adversarial review. AI agents write most of the code and they only follow what's in a file they read. So config and prompts have fixed homes, a bug fix starts from a failing test, and every monitor gets registered in a manifest before it exists, and CI fails if those drift apart.

The pipeline polls the NHC every 60 seconds but only wakes the core database when an advisory actually changes, roughly 8 to 15 times a day plus a few discussion updates. Nineteen health checks watch the system. Four run outside my infrastructure on Grafana (the fastest every minute, the other three every 3 minutes); the rest run on the server's 15-minute loop or the status route. Two bad checks in a row open an incident that says what's down and what still works, with links to the right logs. When things recover the incident closes, and every resolved one gets a written postmortem because the constitution requires it.

Since this summer it also repairs itself. It attempts every failure its own monitoring detects. There is no approved list. Incidents that affect the resolver itself are left out. Otherwise the session writes a fix and opens a pull request, the fix goes through the same CI checks as my changes, it ships, and then the live site gets checked. It isn't allowed to add features, data sources or pipelines, change the layout or interface, or do performance work. That rule is written in the instructions each session gets, and every incident it's handed is about something that broke. Nothing in the code stops it from editing any file. How HurricaneWise ships its own repairs goes through the controls.

My cost model puts it at about $15 in a typical month and about $40 in a stormy peak month, and $7.60 of that is the server.

How big it is

It's a public weather read that regenerates all the time, with no accounts and no personalization. The personal data it keeps is what the feedback form needs to stop abuse: the submitter's IP and browser string. At that size I can check every number myself in an afternoon.

I still run it the way a company runs a product, which works out to nineteen disciplines. Three of them I'd never done before: legal, branding and design, and marketing and search. The full map is here, with the work in each one and the call I made.

Operations mostly runs without me now. I still decide what the product does, what gets built next and what to do with user feedback. I'm using the same approach on Longview, which runs my house. It's private by design and holds household records, so its repair agent is structurally barred from merging or deploying.

What I'd tell a friend

I wrote my rules down early (one source of truth, a test with every change, a failing test before any bug fix, secrets in a vault), and I spent a lot more time holding the AI to them than holding myself to them. With tools I hadn't used, I let the AI do the setup and checked the limits it reported myself. I'd also add monitoring early, while the system is small enough that a wrong check is easy to spot. My first health probe looked at whether its own loop was running and never at the advisory's age. I fixed it and added a test before automated repair was anywhere near the release path.