A fishing forecast, from a question to a live product.
This is where "I build the real thing" stops being a line on a page. I built ReelCaster with its founder — I designed the product, implemented the front-end, and built the design system, while an engineer built the core. A live product on real forecast data, not a prototype.
A dozen tabs of homework, and you still guess.
To decide whether a morning on the water is worth it, an angler cross-references tide tables, marine weather, water conditions, and a maze of regulations that change by species, area, and date. It's real work, and it still ends in a guess.
The regulations are the trap. They live across government pages, written for enforcement rather than reading, and getting one wrong isn't an inconvenience — it's a fine, or a closed fishery, or worse.
All of it had to collapse into one number.
My part was the product: the design, the front-end, and the design system that holds it together. The core move was reduction — fuse tides, weather, ocean state, species behaviour, and current regulations into a single 0–100 score for a given spot, species, and hour, so the go/no-go call takes two seconds instead of twelve tabs.
One number is a strong claim, so the product has to earn it. The score stays transparent about why it's high or low, and it degrades honestly when the data is thin rather than faking a confidence it hasn't got.
I designed it and implemented the front-end in the same repo our engineer worked in — not a spec handed over a wall. That's what kept the design and the shipped product the same thing, down to the last token in the system.
Showing all the dataThe default weather-app answer: charts of everything. It just rebuilds the twelve tabs on one screen and hands the synthesis back to the angler, which is the exact work I set out to remove.
Trusting the extraction to be "close enough"Faster to ship, and wrong for a domain with legal limits. A confidently-incorrect number is the one failure you can't allow, so the system is built to refuse rather than guess.
The forecast was the easy half. The rules were the hard one.
An LLM reads live government pages to pull catch limits, closures, and size rules. The tempting failure is subtle: when a page truncated mid-parse, an early version quietly saved a partial rule set — technically "successful," actually wrong, and invisible until someone got fined.
So we made it fail loudly. A truncated or low-confidence read is rejected, never written, and the product will show nothing before it shows a wrong legal limit. In this domain, missing is recoverable and wrong is not — the product is designed around that asymmetry.
Data that has to be right the first time?
Start a project