It is a small application, but it has the shape of a real product: backend data fetching, caching, scoring, frontend display, and deployment.

Why build it

Fishing decisions depend on several signals:

• tide timing
• weather
• wind
• rain
• forecast window
• saved locations

Generic weather apps show the raw pieces, but they do not answer the combined question I care about. A personal dashboard can make that tradeoff directly.

Architecture

The backend is a Cloudflare Worker. It fetches marine/tide data and weather forecasts, computes a score, and caches results in Workers KV.

The frontend is an Astro and React app deployed to Cloudflare Pages. Shared TypeScript code keeps constants and data shapes aligned.

This is a good fit for Cloudflare because the workload is small, read-heavy, and cacheable.

Privacy and scope

The app is intentionally personal and ad-free. It does not need accounts, social features, or public rankings. It needs to answer a small question reliably.

The main external dependency risk is data quality and API availability. That makes caching and clear failure states important.

What I learned

Personal dashboards are worth building when they compress repeated decision-making. The value is not that the app is complicated. The value is that it turns several tabs and mental calculations into one screen.

The scoring model should also stay humble. A “good fishing day” score is a decision aid, not a guarantee. The app should make the inputs visible enough that I can override the score with judgment.

Current status

good-fishing-day is private because it is tied to personal usage and deployment details. The architecture pattern is reusable: small Worker backend, cached external data, static frontend, and a domain-specific score.