slackfin
Tide, weather, and an AI fishing read.
- Role
- Design + Engineering (solo)
- Timeline
- Concept to live deployment
- Live
- slackfin.com
Checking conditions before a trip to Fox Island Pier meant four separate tools: a tide app, a weather app, a gut read on pressure, and whatever I half remembered about how this spot fishes on a given tide. None of them talked to each other. None knew anything about this pier specifically. There was no single honest answer to the only question that mattered: is it worth driving out right now.

The problem
Four tools. No shared answer. No way to check any of them against this specific pier or against each other.
Constraints, on purpose
Before any design work, I wrote down what this wasn't going to be. Scope creep is the most common way a project like this stalls.
- One pier, one marine area, not a general-purpose fishing app
- No accounts or login. Friction has to earn its way into a single-user tool
- Mobile web, not native. The real test is a phone with weak signal at the pier
- No guarantee of anything. It reads conditions. It doesn't promise fish
Process
1. Research the actual complaint, not the assumed one
I looked at what anglers actually complain about in Puget Sound fishing forums before touching the score model. The most repeated frustration wasn't tide timing. Every tide app gets that right. It was tide height diverging from prediction because of wind: east wind means high water, west or north wind means low water. Every existing app showed the harmonic prediction only, never what was actually happening to the water. That became the single most important feature decision in the project.
2. Design a score, but design the honesty around it first
A single 0–100 conditions score is the whole point of collapsing five inputs into one read, but a bare number invites false confidence. So the "How this score works" panel was designed alongside the score, not bolted on. It names exactly which factors are weighted (tide movement, dawn/dusk light, pressure trend, wind, moon phase) and states plainly that this is a heuristic, not a guarantee. The catch log exists partly so the score has something to be checked against over a season.
3. Let the AI verdict explain, not invent
The plain-language read at the top is written by Claude, constrained to the same facts a human would have: tide direction and rate, pressure trend, wind, moon phase, the best predicted window. It has an explicit instruction not to invent regulations or facts outside the given data. I settled on a VERDICT / WHY structure after finding that unstructured prompting produced rambling, inconsistent output. The structured format gave scannable results every time.
4. Solve the wind problem NOAA doesn't solve by default
NOAA publishes two numbers at sensor-equipped stations: the harmonic prediction and the observed water level. The gap between them is wind and pressure's real effect, the exact thing anglers said no tool showed. Fox Island's nearest station (Gig Harbor) has no sensor, but the fallback (Tacoma) does. slackfin folds Tacoma's observed-vs-predicted offset into both the score and the verdict's reasoning, while stating plainly in the UI that this is a regional proxy read of the last day, not a forecast.
5. Design the system, not just the screen
I built a named palette (ink, paper, tide, bite, kelp, slack) and paired a serif for the wordmark and AI verdict against a monospace for numeric data and a sans for UI chrome. The voice reads as considered and calm rather than like a generic dashboard, which matters when the product's whole value is trust in the read.
6. Iterate the details in motion
Some decisions changed shape after being built and tested. The score display started as a rotated stamp and settled into a straight circle. The factor breakdown became a bar visualization after the first version didn't make clear why a score was what it was. A late mobile-contrast failure (WCAG AA) led to adding the slackDeep color rather than compromising on readability.
Key product decisions
| Decision | Why |
|---|---|
| Anonymous, device-token ownership for the catch log | Per-user data ownership without the friction of a login flow |
| AI routed through a Supabase Edge Function, not the browser | Keeps the Anthropic API key off the client once the tool went public |
| Regulations panel links out, never restates limits | Season rules change. Restating them risks being confidently wrong |
| Local heuristic verdict as a fallback | If the AI call fails, the app still answers instead of breaking |

Outcome
slackfin is live and in real use at Fox Island Pier, tested on cell signal at the location it was built for. It shows a hiring team a personal problem scoped into a real product, a design system built with the same intentionality as the code, an AI feature designed around grounding and honesty rather than novelty, and the judgment to know what not to build yet.
What's next
Once a season of catch data accumulates, the natural next step is checking the score heuristic against what was actually caught. Does outgoing tide really correlate with catches at this pier? That's the question the tool was built to eventually answer about itself.

